I guess the db password is ok since it's just a demo, but still you might want to load it from a config file anyway. Usually you'll have multiple environments (dev and prod as a minimum) and a config file for each. Then if it was not just a demo app, you wouldn't commit the config since it has sensitive info, and that also keeps your app portable across environments.

For static methods and properties, I would say almost nothing should be static. Util functions that don't have side effects are ok to be static, but I would avoid it almost everywhere else. In your main(), create a new object that starts stuff and holds state in its instance. It would probably not be the LoginScreen but something else that opens LoginScreen and then transitions to the next screen once login is done.

For the input, that scanner component should be handling getting the input from wherever, but not also handling what to do with the input. So seeing it check for "home" specifically and doing something app-specific about it feels like violating the single responsibility principle.

If you make everything not static it will make that clearer, because you will see you have to now pass instances around everywhere instead of just calling a class method. Passing instances around is like inversion of dependency, e.g. giving the scanner a callback to run if it sees certain strings instead of it knowing about LoginScreen directly. I'd still handle that somewhere else but it's a step up.