In the time it takes a big team to schedule a pre-meeting for discussing changing a schema, solo-devs can whip through many huge cross-cutting refactors across their entire architecture without anyone complaining about broken merges.
Building a real, successful thing generally involves more time and more learning about the customer space than you expect at the outset. As a single dev, you have a massive advantage over big teams in your ability to make huge fast change in the architecture of your product.
Here's the controversial part of this: if you want to maximize your ability to make big changes, you want a strongly-typed codebase (for me that's TypeScript on the front-end and C# on the backend because of the quality of the refactoring tooling for it). There's no formal guarantee that strong typing will keep your code working across big refactorings, but in practice it just works. You focus on getting the inner loops right and the compiler and IDE takes care of the rest.
Yes, you can probably write the first iteration faster in a dynamically typed language, but when you start making those big changes that are your unfair competitive advantage against larger teams, the strong typing combined with modern IDE tooling capabilities means a working system remains a working system even as you treat it like completely malleable clay.
I'm also a fan of modular monoliths, again for ease of major refactoring (if you're not familiar with it, check out for example TurboRepo in the node.js space). You can organize an enormous amount of code well using this technique, including having things partitioned to hand off to other devs or multiple teams if you happen to eventually want to scale up from single dev to multi-dev.