If you're absolutely sure that you need a mobile app, and you say you validated that users say a mobile app is a needed as a solution for That Problem:
How about you write a minimum app for That Thing to do that one (or 2) main thing that your service does, but not everything. If that'll have a good number of downloads, then that's a good validation.
* A small product is also easier to outsource.
* I did tiny test projects with applicants before, and it worked well.
Join a co-working space, work from cafes (can be hard too) or rent an office with friends. Why? Keeping the work at work and enjoying the time at home will be a good strategy against burning out.
Of course it will take you some time to commute or be more expensive than just staying at home, but it's a good way to stay sane. Maybe you can also create your own office in 1 room and be at home in the other rooms. But you might be tempted to work longer than what is healthy.
This is very dependent on the project size, team size, team knowledge, but ...
I would turn it into a habit, maybe a mini habit because you're busy. A mini habit is something "too small to fail" that you do every day/week or every time you commit.
* Read through all the changes you're going to commit. It's amazing how much you can spot by yourself when looking at it again. For every change ask yourself, could any of the variables/parameters be in some way malicious (nil, empty, something malicious only in this context). That's not the only thing to check, you'll have to know other types of vulnerabilities, too. But it's a start.
* If you're in a team, you could do the same by asking coworkers for reviews and use pull-request cycles.
The advantage of these small steps are that you won't need to reserve a _huge_ block of time for an audit just before release. And if you do reviews in a team, you'll also get somewhat of an outside view on the code. That doesn't mean of course there won't be any vulnerabilities anymore, but it can greatly increase code quality. A professional audit will still spot more problems, but I've seen teams getting better and better every time they had an audit.
Sometimes security vulnerabilities aren't directly visible in the code because they might only exist because of 2+ other features. For example: Many web applications allow you to change the password, but it requires to enter the old password. Now somebody adds a feature to change the email address of the user. That sounds like a normal feature. It’s secure by itself, because only the user can change her own email. So what if someone gained access to the account (a stolen session/cookie)? That means that someone could take over the entire account by changing the email address. And from there she could use the “Forgotten password” feature to create a new password which will be sent to the new email address.
* So in terms of habits, use some time every week on the same day and think about the bigger picture, the general security policy. And limit the time you spend on this. Otherwise you won’t want to do it next week, because it took too long last time.
