The question isn’t whether to start small or build big. The question is what you’re uncertain about.
If you’re uncertain about what users want, or whether the problem is worth solving, or which approach will work, you start small. Ship something ugly. Get it in front of users. You can’t hide behind architecture diagrams when there’s code running in production.
If you’ve already done the thinking, you know the problem, the constraints, the failure modes. You’re executing on a clear plan, not guessing. The thinking is the hard part. The building is execution.
It changes throughout a project. What you’re uncertain about at the start isn’t what you’re uncertain about in the middle. Your approach should change as your information changes.
The failure mode of starting small is building the wrong thing and iterating forever without converging. You optimize for speed without defining what success looks like.
The failure mode of starting large is building the wrong thing with confidence. You optimize for correctness without validating that what you’re building solves an actual problem. You spend a year on something nobody wants.
Start with a clear definition of the problem and the constraints. If you can’t articulate what you’re solving and why, don’t build yet.
Then build the smallest version that proves or disproves your core assumption. This isn’t being sloppy. It’s being focused. As you gain certainty, expand. Expand because the data tells you the problem is real and the solution works, not because it feels right.
The best builders aren’t the ones who follow a methodology. They’re the ones who know what they’re optimizing for, recognize when they’re wrong, and change course without ego.