You've heard it a thousand times: talk to customers before you code.
But nobody mentions the uncomfortable truth. Some ideas genuinely cannot be validated through conversation alone. You can describe a feature. You can draw wireframes. You can explain the problem it solves. And people will nod and say it sounds great.
Then you build it. And they don't use it.
The issue isn't that you didn't talk to enough customers. It's that talking wasn't enough. Your idea needed to be seen working to be understood.
This is not a failure of your communication skills. This is a fact about your idea.
The question isn't whether to validate. It's whether you need to build something first to do it.
"Talk to customers before you code" is good advice.
It's also incomplete advice.
It works beautifully for certain ideas. If you're building a better scheduling tool for freelancers, you can talk to ten freelancers, hear about their pain, understand their workflow, and validate the problem without touching code. Same for a logistics software, a bookkeeping service, a new kind of CRM.
These are ideas about making existing processes faster or simpler. Customers already understand the category. They can imagine the improvement.
But some ideas live in a different category.
If you're building a completely new interaction model, a product that works in a way people have never experienced, or something that requires understanding a system people don't yet see, conversation hits a wall. You describe it. They picture it wrong. You try again. They picture it differently wrong.
By the time you finish explaining, neither of you knows if the idea actually solves the problem.
Here's what happens next. The founder ignores the advice. Builds anyway. Ships an MVP. And suddenly customers get it. Suddenly the feedback makes sense. Suddenly you know what to build next.
That's not stubbornness. That's not impatience. That's the founder recognizing something the generic advice didn't account for. Their specific idea needs visibility.
Not all ideas are created equal.
Some validate instantly in conversation. Some need a prototype. Some need a working product.
The difference comes down to one thing: how much does a customer need to experience this to understand it?
Ideas that validate without code:
You can test these through conversation alone. Talk to ten customers. You'll know.
These are solutions to problems customers already feel. Problems they can articulate. They know what they're trying to do and they know it's hard.
Examples: a faster way to do payroll, a better interface for project management, a tool that automates a painful spreadsheet task, a service that handles something businesses currently outsource.
The customer can picture these. They can say yes or no based on conversation.
Ideas that need a prototype (low-code):
A click-through prototype. A Figma mockup. A landing page with a video demo. These make the idea visible without building the full product.
Use this bucket when the idea is somewhat new but not alien. When customers might not immediately grasp it from description but can understand it in minutes if they see it in motion.
Examples: a new kind of calendar view, a different way to organize team communications, a UI pattern that solves a known problem in a novel way, a scheduling experience that works differently than existing tools.
Show them the prototype. Watch them use it. Their response will be honest.
Ideas that need a working product:
These are the ones that require code. Not because you're impatient. Because there's no other way to validate them.
These are ideas where the value emerges through use. Through experiencing the system working. Through seeing how it behaves in real time. Through understanding the flow and the logic and the feedback loops.
Examples: an algorithm that needs to perform correctly to prove its value, a system that requires real data to demonstrate its advantage, a tool where the user experience depends on how the system responds in real time, something that changes how people think about a problem because of how it works.
You cannot validate these in conversation. You cannot validate them with a prototype. The idea only makes sense when it actually runs.
This is where founders get stuck.
On one side, there's the fear of building the wrong thing. You code for three months. Nobody wants it. You've burned time and money and momentum on a false start.
On the other side, there's the credibility problem. You talk to potential customers about something that doesn't exist. They listen politely. They say it sounds interesting. But there's a gap between "sounds interesting" and "I would use this."
Most advice pretends one side doesn't exist. It tells you to do whichever thing is cheaper or faster.
But the real calculation is different.
If you build and you're wrong, you've wasted three months and some money. But you've also learned something only building can teach you. You've moved fast. You've derisked the core question: is this idea even buildable the way I imagined it?
If you talk and validate and then build, you've avoided building the wrong thing. But there's a hidden cost. You've moved slow. You've created attachment to validation that may not survive contact with reality.
The honest choice depends on your specific idea and your specific situation.
Some founders should talk first. Some should build first. Many should do both, in sequence.
The trick is knowing which.
If your idea needs code first, there's a right way and a wrong way to do it.
The wrong way is treating this as a green light to build the full vision. You get excited. You start coding the feature-complete version. You're going to validate "properly."
Six months later, you have a feature-complete product nobody wants. You've proven that building won't validate your idea either. This is where many founders end up, and it's often because your MVP was too big in the first place.
The right way is building with constraints.
Build the core interaction, not the full product.
If your idea is valuable because of how the system behaves, build only the part that demonstrates that behavior. Leave everything else out.
A tool for real-time collaboration? Build the collaboration part. Forget the admin panel, forget advanced permissions, forget the export features. Does the collaboration work? Does it feel right? Does it solve the problem? Everything else is distraction.
Use real data, not fake data.
If your idea depends on demonstrating value with real information, use real data from day one. Not because you need scale. Because you need honesty. Fake data lies. Real data tells you if your idea actually works.
Talk to users while you build, not before.
The worst time to talk to customers is before you have anything to show. The best time is after you've built something they can actually use. Watch them use it. Listen to what breaks. Don't ask if they like it. Watch if they keep using it. This is fundamentally different from the validation conversations most founders conduct before they've built anything.
Set a deadline.
This is not about moving fast for speed's sake. It's about forcing you to build only what matters. If you have four weeks to validate your core idea, you will only build the core idea. You will cut everything else. That's what you want.
Validation is not a stage you complete and move past.
Validation is the process of checking your assumptions against reality. Conversation is one way to do that. Code is another way. Prototypes are another way.
Some assumptions can be checked through conversation. Some require you to build something people can touch.
The difference between a founder who moves fast and a founder who gets stuck is this: know which is which.
Your idea is not "talk-first" or "build-first." It's one or the other based on what needs to be visible to be understood. Look at your specific idea. Ask yourself: can a customer understand the value in conversation, or do they need to experience it working?
That answer tells you your path.
If you've built and you're stuck, if your MVP validated the wrong thing or didn't validate anything at all, Acrein Lab helps early-stage founders figure out what to build before it's too late. We work with founders in the BUILD phase to cut through the noise and focus on what actually matters.
The right conversation at the right moment changes everything. Let's have it.
Talk to us