You Don't Have a Software Problem. You Have a Discovery Problem.

The most expensive software project I’ve worked through wasn’t built badly. It was built perfectly.

The founders had spent months mapping it out. Detailed specs. Wireframes for every screen. The dev team executed cleanly. The product launched on time and under budget.

Almost nobody used it.

The problem wasn’t code quality. It wasn’t architecture. It wasn’t the team. It was that the product solved a problem the founders assumed existed, based on how their business worked two years ago, without ever stopping to validate whether that assumption was still true.

Three months of engineering. A clean build. And they were solving for the wrong thing.

This is the mistake I see more than any other. Not bad code. Not slow teams. Not tech debt. Just: the wrong build.

The Step That Costs You When You Skip It

Most founders treat software development like this: figure out what you want, hand it to the developers, ship it.

That’s not a process. That’s a theory.

The missing step is discovery: a deliberate, time-boxed phase of understanding the problem before you decide on a solution. Not a kickoff call. Not a requirements doc that captures what you already believe. An active investigation into what’s actually happening, for the people who have the problem, in the work they do every day.

Discovery means sitting down with the people doing the actual work, not just the executives who manage them, and asking uncomfortable questions. Not “what should the system do?” but “walk me through what you do when X breaks down.” It means following the workarounds: the spreadsheet someone built because the ERP doesn’t handle their edge case, the Slack thread that substitutes for a missing integration, the four-step manual process that exists because nobody ever built the right button.

The workaround is almost always the most honest signal of where the real problem is.

I had a conversation recently with a growing manufacturing company. Multi-region operation, moving product across multiple states and into Mexico. They’d been using the same ERP for years. It worked fine at one facility. At five, it was breaking down.

They came to us wanting to replace the whole system. Their pain was real: three people in three locations entering the same inventory item under three different names, creating duplicate records and ordering mistakes. Communication across regions was disjointed. Reporting was manual and took hours.

The instinct is to scope the replacement ERP. That’s a 12-month project and a significant budget commitment.

The better question was simpler: what is the smallest thing we can build in six weeks that solves the most expensive pain point? Not the full ERP. Not the five-year vision. One tool. One problem. Six weeks. Validate that we understand it and can solve it, then decide whether the bigger investment is warranted.

That’s a $10,000 question before a $200,000 commitment. And the answer to it changes everything.

What Skipping Discovery Actually Costs

Here’s the math that nobody does before they start building.

A proper discovery engagement, depending on scope, runs one to six weeks. The output is a clear problem statement, prioritized pain points, rough user flows, and a phased roadmap. For most projects, that’s $5,000 to $20,000 in time and money.

The cost of skipping it and building the wrong thing: research consistently puts rework at three to six times what discovery would have cost. Build the wrong thing, or build the right thing structured incorrectly, and you spend the next year doing partial rewrites and patching holes instead of shipping features.

I’ve seen companies spend $60,000 undoing an architecture decision that a two-week discovery would have caught for $8,000. That’s not a hypothetical. That’s a pattern.

The reason founders skip discovery isn’t carelessness. It’s impatience and misplaced confidence. You’ve been thinking about this problem for months. You know what needs to be built. Why slow down with more questions?

Because you have a theory. Discovery tests it against reality. And reality is more complicated than any theory, including ones built by smart, experienced people who know their business well.

The founder with the three-month spec that solved the wrong problem knew their business. They just knew it as it was two years ago.

The Over-Engineering Version of the Same Mistake

There’s a technical variant of this failure that shows up on the development side.

A startup decides to build their first product. The technical team gets involved early, which is good. But instead of scoping to what the product needs for their first 1,000 users, they architect for ten million. Microservices. Kubernetes. Event streaming infrastructure. All of it real, sophisticated engineering.

It takes four months before any product code gets written.

A monolith would have taken six weeks, cost a fraction of the budget, and scaled cleanly to their first 50,000 users. By the time they actually needed distributed architecture, they’d have had real usage data: which parts of the product got hammered, which were barely touched, where the actual scale pressure was going to come from.

Instead, they burned four months of runway on infrastructure for a product that hadn’t validated a single assumption yet.

Over-engineering is the same failure as the wrong build. Both come from skipping the question: what do we actually need to solve the problem in front of us, right now, with the information we currently have?

The answer is almost always smaller and simpler than the first instinct.

What Discovery Actually Involves

If you’re about to start a software project and haven’t done this, here’s what the phase looks like.

The first week is listening. Talk to the people who have the problem, especially the ones doing the work, not just the ones managing it. Ask them to walk you through their process step by step. Where does it break? What do they do instead? What takes longer than it should? The workaround is the signal.

The second week is mapping. Take what you heard and turn it into a simple picture of the problem: where the pain actually lives, what causes it, what it costs the business. Not wireframes yet, not mockups. Just clarity on the problem itself.

The output is a short document: three to five prioritized pain points, a proposed first phase that addresses the most expensive one, and a rough scope of what building that costs and takes. Everything else goes into a backlog for later phases.

That document is worth more than any spec you’d write before doing this work. Because it’s grounded in what’s actually happening instead of what you believe is happening.

It’s also the document that saves you from spending six months building something that doesn’t get used.

The Question That Changes Everything

Most founders start a software project asking: “How fast can we build this?”

The question that actually matters: “Should we build this at all, and if so, what’s the smallest version that proves the idea?”

Those questions lead to completely different projects, timelines, and outcomes.

I’ve worked with founders who spent six months building something nobody needed because they never stopped to ask the second question. And I’ve worked with founders who ran a two-week discovery, found out their instinct was right about 70% of the problem and wrong about the other 30%, and used that to build something users actually adopted in the first month.

The second group didn’t go slower. They went smarter first, then faster.

If you’re staring down a software build right now, whether you’re replacing a system that stopped working or building something new from scratch, spend two weeks on discovery before you spend two months on code. Talk to the people with the problem. Map what you find. Define the smallest thing you can build that actually matters.

The founding team that ships the right thing six weeks later will always beat the team that shipped the wrong thing six weeks sooner.

If you’re not sure whether your current project has gone through this step properly, or you’re about to start building on a foundation of assumptions, that’s worth a conversation. I’m easy to reach.