Any thoughts on how I can overcome this mental block, and to ensure my app will be scalable?
The crux of the issue isn't scalability. The crux of the issue is thinking that you will get it right the first time.
You should focus on writing clean code. Because clean code maximizes convenience when you (inevitably) have to change something in the future. And that's the real goal you should have.
What you're trying to do now is try to think of the perfect code to write. But even if you manage to do that, who says the requirements aren't going to change, or you maybe made your decisions based on wrong information or miscommunication?
You cannot avoid making mistakes, even if they're not your fault. Focus on writing code in which it's easy to change things later, instead of hoping to write code that you won't need to change in the future.
Having grown attached to the project and the code I've already written,
I absolutely sympathize with this sentiment. But getting attached to the code you've written is a problem.
The only thing that should be a constant is your desire to solve a specific problem. How you go about solving that problem is only a secondary concern.
If tomorrow a new tool is released that reduces your codebase by 80%, are you going to be upset that your code is no longer used; or are you going to be happy that your codebase has become smaller and much cleaner/more manageable?
If the former, you have a problem: you're not seeing the solution for the code. In other words, you're focusing on the code and not seeing the bigger picture (the solution it aims to provide).
I'm scared that all additional work I commit will be overturned in the near future, when the app turns out to not scale well as the business grows.
That is a different problem for a different day.
First, you build something that works. Secondly, you improve the code to fix any flaws it may still show. What you're currently doing is holding back on the first task out of fear of then having to do the second task.
But what other option is there? You cannot tell the future. If you spend your time pondering future possibilities, you're going to end up guessing anyway. A guess is always prone to being dead wrong.
Instead, build the application, and prove that there is indeed an issue. And once the issue is clear, then you start addressing it.
To put it another way: Henry Ford never built a car that conforms to 2018 standards/expectations. But if he hadn't built the Model T, a flawed car by modern standards, no one would have started using cars, there would be no car industry, and no one would have had a car that they could then try to improve.
I've had employers question my choice in not using any web frameworks during interviews, which has only caused me to further doubt my previous work.
The important part here is not which framework you're using (any employer who judges you on that is not doing their job properly). The important part here is knowing what you're doing and why you're doing it.
For example, you could be avoiding existing framework specifically because you want to learn why a framework is useful by doing it the hard way first. Or you could be trying to make your own framework.
The only bad answer here is "I don't know", as it shows a lack of making informed decisions. That is a red flag for an employer.
I simply don't know any web frameworks, and don't know which one to start using.
The same problem arises here. The solution is not to think more, but rather to act:
- Stop pondering the perfect answer.
- Pick a framework. Unless you have a preference, pick a random one. Use a dartboard, roll a die, flip a coin, pick a card.
- Use it.
- Did you like using it? Was there anything you found annoying?
- Look up how to prevent these bad elements. Did you misuse the framework, or is this just how the framework is supposed to work?
- Once you feel you have a grip on the framework (regardless of whether you like it or not), pick a new framework and repeat the cycle.
To read more on this, read The doing mindset > the thinking mindset. The author explains it better than I can.
but the pressure to finish the app is mounting, and I'm considering scrapping the app completely and starting over
Unless the current codebase is an absolutely unmaintainable mess; you're making the opposite decision.
Developers often think that throwing things out would be the better choice. It's a very common feeling. But it is rarely the right choice.
Throwing code out and starting from scratch is like getting stuck in traffic on your way to work, worrying you'll be late to work (miss the deadline), and instead drive home and try driving down the same road again. It doesn't make sense. You may be stuck in traffic, but you're still closer to work than you were when you were at home.