Definition: A startup is an organization formed to search for a repeatable and scalable business model.
Early in a startup, you're heavily focused on research, not development.
Stage 0: Make sure there's a market for your "code"
You should optimize for maximum pivoting speed early on. That means your code is horrible, it is disposable, and it will break. You might even want to think outside the box for this - your stack might not be React/MongoDB, and so on. It might be HTML + Google Sheets + some $5/month thing that converts Google Sheets into an API.
Disposable is key for speed. Expect to do hundreds of prototypes before you hit something good.
At some point, you'll jump from a trickle of 4 users/month to 200 users/week. I would say that it's not startup worthy until there are people who are lining up to pay for what you're doing.
Stage 1: Start selling
Now you've got people lining up to pay. You have to prove the next risk: payment. Calculate how much money you need to actually build a self-sustaining business where everyone can quit their jobs. What's the simplest thing you need for this? 1000 customers paying $10/month?
Aim for that. If you want to be a little more ambitious, go for 10x, about 10,000 active users/month.
This depends a lot on what you're doing. Let's say you're doing a sales management tool for used car salesmen and need to track the condition, repairs, costs on a used car, complaints, etc. You can probably repurpose an existing CRM's API, or use some open source code. There will be issues with flexibility and scaling, but you just want to hit 1k-10k paying users.
Or if you're doing debt collection for babysitters, you can use some debt collection software, link it to a quick and dirty database, and give it a suitable UI for babysitters.
Once you can secure a stable cash flow, you'll be in a good negotiation position for investors. It's easier to say, "I have 1k customers and need funds to get it up to a million," rather than say, "I want to build something for a million customers and the estimated market size is this big."
Stage 2: Start growing and scaling
So by now, you should have a loyal customer base that throws money at you, and some funds to improve your software.
Next, look for the bottleneck to getting 7% more revenue next week. It could be more users. It could be existing users wanting to pay more for another feature, or requiring that feature before they pick you over the competition. It's rare that people leave because of a few bugs.
Under that growth target, you can expect to scale about 10x per 8 months. So, you don't have to build something that supports a million active users right away, but it should be on your roadmap for the next 16 months.
Build a good pipeline. You'll see cracks in yours - maybe compiling takes a long time. Maybe there's a lot of null pointer errors. Maybe juniors are pushing breaking code to production. Find what it is, and patch a solution for that. Every team is different.
Don't build the best pipeline, not yet. Overengineering is much harder to fix than underengineering.
Stage 3: Start stabilizing
At some point, the sales/marketing team will no longer be tightly coupled with the product/engineering team. Users are no longer looking for new features. They just want it to do what it does, better and more reliably.
By now, you probably have a monolithic mess. You'll have spaghetti code from juniors and freelancers, that feature that you put in but nobody wanted, tech cofounders who ragequit, hacky fake code written by cheap people you hired because you couldn't afford anyone else.
Start documenting and writing automated tests. I know this is controversial to start this late, but too early, and you run the risk of documenting/testing something that gets thrown away. Documentation tends to be hard to read, and people are going to ask anyway.
"But what about if an early stage programmer leaves and won't communicate with the team?" Then it's likely that the code doesn't work as documented, especially if you haven't had automated tests yet. It's also quite common that code was intended to run one way and does an entirely different thing later and someone forgot to update the documentation.
You might want to hire/promote a system analyst at this stage. This is a person who knows all the hacks that were used at some point and whose full time job is to provide support and say, "Oh that thing doesn't actually work that way," or "We did that because of a rare use case or limitation in the technology." If you make a programmer or manager do this part-time, they tend to bury problems or blame someone for not RTFM. System analysts also help to fix the process - if they're getting a lot of complaints and confusion for one thing, they'll know that something in the pipeline is flawed.
So in short, the code itself isn't too tough. As long as it runs well, sells well, and doesn't fall apart, it should be fine. In a startup, you end up engineering your processes and your team more than the code.
Also don't forget to engineer the cycle between customer > product > UI/UX > development > QA/testing.