There's a moment in every project where you realize you've been building the wrong thing.
For us, it happened on a client project last year. Three weeks of clean code. Solid architecture. Tests passing. Then we showed it to actual users and watched them struggle with the core flow we thought was intuitive.
We didn't have a code problem. We had a clarity problem.
The pattern we kept seeing
We're a lean software studio. We build prototypes and MVPs for startups and companies. And the pattern was always the same:
Client comes in with an idea. Idea sounds great in a meeting. Everyone's excited. We start coding. Weeks later, something feels off. Users don't behave the way we expected. Features that seemed essential get ignored. The thing nobody asked for turns out to be the thing everyone actually needs.
Sound familiar?
What we changed
We stopped starting with code.
Not permanently. We still write code every day. But we stopped making it the first thing we do.
Now, before we open an editor, we do three things:
- A clickable prototype that feels real Not wireframes. Not sketches on a napkin. A Figma prototype that looks and feels like a real product. No backend, no database – but real enough that when you put it in front of someone, they try to use it.
This takes us 2-3 days. It used to take weeks. AI tools like Figma Make help, but the key insight isn't the tooling – it's that a prototype answers questions a meeting never will.
- Five conversations we don't want to have We put the prototype in front of 5-8 people from the target audience. Not friends. Not the client's team. Actual potential users. And we don't ask "do you like it?" – that's a useless question. Everyone says yes.
We ask: "Show me how you'd do X." Then we shut up and watch.
Where do they hesitate? Where do they tap the wrong thing? Where do they say "wait, what does this do?"
Every moment of confusion is a feature we would have built wrong.
- Actively looking for reasons it won't work This is the counterintuitive one. We go into user conversations looking for the "no." "I would never use this because..." "This doesn't solve my actual problem because..." "I already handle this with a spreadsheet and it's fine." One honest "no" is worth more than ten polite "sounds interesting." What happens after
Only after these three steps do we write code. And by then, something has shifted:
- The feature list is shorter (usually 40-50% shorter than the original spec)
- The core flow is different from what everyone assumed in the kickoff
- The client has seen real user reactions, not just our opinion
- We know why we're building each feature, not just what
The numbers behind this
This isn't just our experience. CB Insights analyzed hundreds of startup post-mortems and found that 42% failed because there was no market need. Not bad code. Not running out of money. Building something nobody wanted.
The Startup Genome Project found that premature scaling – building too much before validating – kills 70% of startups. Teams that scale prematurely have 20x lower growth rates.
Think about that: the biggest risk isn't writing bad code. It's writing good code for the wrong thing.
"But we don't have time for validation"
This is the objection we hear most. And it's backwards.
You don't have time to not validate.
Two weeks of prototyping and user testing costs a fraction of what six months of building the wrong product costs. We've seen this play out multiple times: a client comes in wanting to build Feature X, we prototype it, test it, and discover that users actually need Feature Y. The prototype cost days. Building the wrong feature would have cost months.
How AI changes this (and how it doesn't)
We use AI heavily. Claude Code writes our implementations. Figma Make generates design drafts. Gemini handles competitive research. AI is involved in 6 of our 12 workflow phases.
But here's what AI doesn't do: it doesn't tell you whether you're solving the right problem.
AI makes building faster. That's genuinely useful. But if your direction is wrong, AI just gets you to the wrong destination more efficiently. The code will be clean. The architecture will be solid. And the product will still miss.
That's why every AI step in our workflow has a human gate after it. AI proposes, humans decide. Not because AI is bad – because speed without direction is waste.
The uncomfortable truth
Most of the value we deliver to clients isn't code. It's the moment in a user test when someone says "I don't need this" and saves the client from building it.
That moment is uncomfortable. Nobody wants to hear that their idea needs changing. But it's infinitely cheaper to hear it from a prototype test than from an empty dashboard after launch.
If you're about to start building something – a side project, a client project, a startup – try this before you write your first line of code:
Build a clickable prototype (Figma, even just screenshots stitched together)
Put it in front of 5 people who have the problem you're solving
Ask them to use it, not whether they like it
Listen for the "no"
It might save you months.
We're the team of decivo. We build prototypes and MVPs for startups – with an AI-powered validated workflow
