The Overbuilding Trap
Is your simple MVP quietly becoming the bloated product it replaced?
I was talking to someone the other day and they were describing how they had built a tool to make sense of documents they’d been given - files they couldn’t read, reports they couldn’t interpret, in a domain where they had no training. They weren’t trying to build a startup, or a full fledged product. They were just someone who decided to build their way to an answer.
I’ve heard versions of this story countless times now. Tools to make sense of taxes, navigate government loans, understand medical scans. Tools to answer the one question a finance app somehow can’t. None of these people were trying to build the next Mint or Robinhood or Horos - they were trying to understand their own situation, and figuring out what an MVP even looks like for a user base of one.
What I love about these projects is who’s building them. People who wouldn’t have called themselves developers two years ago, and people who didn’t necessarily know anything about the domain they are building in when they started. So why is this happening now? Because AI collapsed two barriers at once: you no longer need to know how to code to build software, and you no longer need to be an expert to walk into a domain. You just need a problem to solve - and oftentimes the problem is something that’s yours.
When people start building I find that the first version is often delightful. It’s easy to look at the incumbent software - the bloated, hundred-setting, twelve-menu thing - and realize most of it can go. The model can make smart decisions the old software forced onto the user. Whole workflows collapse into a single screen. You build the one thing you need, and it’s clean and simple and exactly right.
It’s easy to make the first version gorgeous - but It doesn’t always stay that way.
The Trap
Here’s the pattern I keep seeing, whether it’s a personal tool or a real product with real users.
The MVP works. People use it - maybe just you, maybe thousands. And then the feature requests start coming in - from users…from you. You’re learning the domain through the product, and the more you understand it, the more you can see what’s missing. In some cases it might be that the settings you proudly scrapped in version one turn out to have existed for a reason - so they start coming back. In other cases it could be that the MVP leads to users wanting more from the product, so you expand outwards.
The features start rolling in. Each addition makes sense in isolation, they’re small and incremental and there’s always an obvious place to bolt it on - a tab, a menu, a setting adjacent to the feature it extends. Nobody sets out to build a bloated product. You get there one perfectly reasonable feature at a time.
Now, there’s a fair counterargument here. You might find yourself thinking “sure, the product got complex - but it’s also far more capable than the legacy thing it replaced so that’s ok.”
I’d push back. The problem isn’t that the product got complex. The problem is that its shape went stale. If you stepped back today and rethought the whole thing - knowing what you now know about the users, the domain, and what the models can do - would you really build what you’ve ended up with? Or would you build something different? The features could be fine, even desirable - but has the architecture of the experience expired?
This trap is nothing new. Every product person who’s been around long enough knows it. What’s new is the pace. A product’s shape used to take years to go stale. Now it can happen in months - the models improve, the workflows shift, and the design you shipped in spring feels dated by fall.
The good news is that the cost of building collapsed at the same time. Rethinking a product from scratch used to be so expensive that bolting on was the only rational move - a rebuild meant quarters, if not years, of engineering time and a migration nobody wanted to own. Now a rebuild can happen in a fraction of that time. “Should we just rethink this entirely?” was never something you would seriously ask. Now it’s a real option worth considering.
The Farm Stand
I can’t stop thinking about this one particular farm stand we drive by often - it perfectly captures what I’m seeing happen with how I’m seeing people building today.
I have to assume that it started the way farm stands usually do - a side channel for the farm. You’ve got surplus produce, a road with traffic on it, and a shed costs almost nothing - so you put out berries, tomatoes, squash, some eggs, and see who stops. It’s low cost and low risk, a cheap test of whether anyone wants to buy direct. A farm stand is, quite literally, a farm’s MVP.
This one worked. More people started coming, so the stand got a little bigger. Maybe someone asked about pies, so now there are pies. Then I assume some people wanted to bake the pies at home, which is why there are now frozen pies - which means freezers, which means running electricity to a shed that was never really wired for it. Then people kept getting hungry on their way through (I certainly do), so a food truck is now parked outside. They eventually got enough foot traffic that they realized they needed bathrooms - so now there’s a row of Port-A-Poties in the parking lot..
Every single step made sense. I want to be clear about that. Each one was a reasonable response to a real need. And yet, in the last few weeks, two miles down the road, a new place appeared. A proper barn-shaped storefront. It has real electricity, running water, clean bathrooms, an actual frozen aisle, and I wouldn’t be surprised if it opened up its own cafe. Someone had looked at that organically sprawling fruit stand and seen it for what it was: proof that the demand existed, wrapped in a shape that no longer served it. They didn’t iterate on the shed. They reimagined the whole experience.
The stand proved the market. The barn is taking it.
The Barn Test
The person who built that barn did one thing the fruit stand never did. They looked at everything the stand had proven - the demand, the foot traffic, the pies - and asked what they would build for all of it if they were starting from scratch. You can run that same move on anything you’re building. It’s one question:
If you were starting today - knowing everything you know now - would you build what you have?
Ask it about the whole product, not a feature. That medical imaging tool that’s grown with multiple settings menus and endless tabs? The finance agent that now has categories and dashboards and a budgeting mode? Your actual product, the one with users and a roadmap? If the honest answer is “no, I’d build something different” - that’s not a signal to add more carefully. That’s a signal to stop bolting rooms onto the shed.
The takeaway: “no” is not a verdict on your past decisions. It’s a signal about your next one. Sometimes the “no” only applies to a corner of the product: one journey, one surface, one aging workflow. Some products might deserve to be rebuilt from the ground up, while others never get a wholesale rebuild at all - they evolve in place, Ship of Theseus style, one plank replaced at a time until they’re something new. The failure isn’t any particular answer. The failure is never asking.
The Three Drifts
Here’s the uncomfortable part: the answer to the Barn Test is “no” more often than it used to be, because products go stale faster than they used to. That’s not because we’ve gotten worse at building. It’s because three things are drifting underneath every product right now:
What users need. What users want today isn’t what they are going to want a month from now. As users learn what’s now possible, their problems will get bigger, and their needs will grow. And if you built in a domain you didn’t know - which more builders than ever are doing - you’ve changed too. You understand the space now in ways you couldn’t have at the MVP.
What models can do. Capabilities expand monthly. Features you carefully engineered a year ago might be a single prompt today. Things that were impossible when you scoped the MVP are now the obvious approach. So how can you think bigger?
How people work. The interaction patterns themselves are in flux - what people expect from chat, from agents, from apps. Users are adapting their mental models and workflows in real time, which means the “intuitive” design of last year can feel dated already.
Any one of these drifting is normal product life. When two or three have moved, incremental features stop being the answer. And the pace at which this is happening today is unprecedented.
The takeaway: when the Barn Test comes back “no,” check the drifts to see why. If it’s just user needs, a rework of one journey might do it. If the models or the workflows moved too, you might be looking at a rebuild - the good news is that a rebuild is cheaper than it has ever been.
Keep Popping Up
Years ago I wrote about thinking in four directions when evaluating a product idea - backwards, forwards, deeper, and up and out. That last one, “up and out,” is the move where you pop out of the problem and scan the landscape: has something changed that changes the shape of the answer?
It’s a framework I keep coming back to, but I used to treat “up and out” as a gate you passed through once, before you started building. But only popping out at the ideation phase isn’t enough anymore - you need to be doing it continuously.
The version I believe now is less like a gate and more like a gopher. You’re heads-down digging - building, shipping, responding to users, doing the work. But every so often you pop up, look around, and check the landscape before going back underground. What do my users need now? What can the models do now? How are people working now? Then back to digging - or, if the landscape moved enough, back to the drawing board.
Adding features is the default motion of product work. I’d argue that right now, removing and rethinking features deserves equal standing. Not (only) because simplicity is virtuous, but because the ground under every product is moving fast enough that the product you shipped last spring was built for a world that no longer exists.
Somewhere two miles down the road, someone is looking at your product the way that farmer looked at the fruit stand. They see the demand you proved. They see the shed onto which you’ve been adding rooms. Be the person who builds the barn.
Below, for paid subscribers: six gut checks I use to help me understand when it might be time to rebuild - and when it isn't.
