I've sat in a fair few founder calls now where someone slides over a schema diagram that looks like the wiring behind an aeroplane cockpit. Forty-odd tables, six join tables just to handle "teams", a permissions system built for an enterprise that doesn't exist yet, and a product that hasn't sold a single unit.
Nobody has ever raised a Series A because their database was beautifully normalised. Nobody's first ten customers have ever cared how many microservices you're running. And yet, over-engineering the first build is one of the most common (and most expensive) mistakes founders make before they've even proven anyone wants the thing.
Let's talk about why that happens, and what right-sizing your MVP architecture actually looks like.
Why founders over-build
It's rarely vanity. Usually it's fear, dressed up as diligence. You've read that scaling is hard, you've heard horror stories about rebuilding from scratch, and so the instinct is to build for the version of your company that exists in your pitch deck rather than the one that exists today. A developer (often well-meaning, sometimes just enjoying themselves) will happily build for a million users when you've got zero, because it's more interesting than building for ten.
The problem is that every table, every abstraction layer, every "just in case" feature costs you time and money now, in exchange for flexibility you might never need. That's not diligence. That's technical debt with extra steps.
What actually matters at MVP stage
At the early stage, your job isn't to build the most scalable system in the world. It's to answer one question as cheaply and quickly as possible: do people want this?
That means:
- A data model that matches how your product actually works today, not how it might work in three pivots' time
- Authentication and roles that are simple but secure, not a full enterprise permissions matrix
- Enough structure to move fast without leaving landmines for future you
A good technical partner will tell you the boring truth here, which is that most MVPs need somewhere between five and fifteen core tables, not forty. If someone's proposing wildly more than that before you've got paying customers, it's worth asking why.
The real cost of premature complexity
Complexity isn't free, and it doesn't just cost you in build time. It costs you in:
Speed. Every extra layer of abstraction is another thing to understand, test, and maintain. That slows down every feature you ship after the first one.
Money. More tables, more infrastructure, more edge cases to handle, all adds up to a bigger bill, whether that's your own time or a dev team's.
Flexibility. This is the counterintuitive one. Founders build complex systems thinking it'll make pivoting easier. In practice, the opposite is usually true. A simple, well-understood system is much easier to reshape than a sprawling one nobody fully understands anymore, including the person who built it.
Building it right doesn't mean building it badly
There's a difference between "lean" and "sloppy", and it's an important one. A right-sized MVP still needs:
- Secure authentication, because customer data is customer data regardless of your company's age
- Row-level security if you've got multiple organisations or users sharing a platform
- A data model that can be extended later without a full rebuild
The goal isn't to cut corners on security or basic engineering hygiene. The goal is to avoid solving problems you don't have yet. There's a real skill in knowing which of those two things you're doing, and it's exactly the kind of judgement call that's hard to make when you're too close to your own idea, or when the person building it has an incentive to make the build bigger than it needs to be.
The phased approach
The way we work at Dilligen is built around this exact problem. Rather than trying to spec out the entire eventual platform on day one, we go through Discover, Shape, Build, Ship in phases, pricing each one separately, so you're only ever paying for what you actually need right now. It means the architecture grows with real evidence from real users, instead of guesswork from a spreadsheet.
If you're about to start building and something already feels heavier than it should, that's usually a sign worth listening to. The best time to right-size your MVP is before you've built it, not eighteen months in when you're trying to explain to an investor why half your infrastructure has never been used.
Building something and want a second opinion on the architecture before you commit? Get in touch and we'll give you a straight answer.