Discovery is the only safe way to price software

If you’re a business leader investing in software, it’s tempting to treat development as a purchase order. You define what you want, suppliers quote a price and you move forward. Okay, but custom software doesn’t work like that. It’s not a product you order, it’s a decision-making process with code as the outcome.

Too many executives learn this the hard way and so did I. They approve six or seven figure projects with less due diligence than they’d apply to buying a new 5 figure car. About six months later they stare at a demo that “technically works” but fails to move any key metrics and it’s totally different from what they envisioned on day one.

They skipped or trivialized product discovery, the step where you determine what’s actually worth building, why and how.

Let’s explore what discovery really means, how to do it right and why only then can you produce estimates that mean something.

Product discovery is not a design sprint. It’s not a few brainstorming meetings or a bunch of wireframes. It’s the translation step between the people having a vision and the people building that vision out. It’s an exploration where you and your development partner work to figure out the unknowns.

Think of it as the R&D phase of a product. You’re investing a controlled amount of time and money to figure out what will actually deliver measurable impact and how to get there realistically.

The goals of discovery are simple but powerful:

If that sounds like “a lot before coding,” GOOD.

Skipping discovery doesn’t save time, it only postpones when you discover you’re wrong. Unfortunately by then, it’s already super expensive for both parties.

Imagine approving a warehouse automation system based solely on a flowchart someone sketched in a meeting. The build team starts coding, only to realize three weeks in that operators don’t actually use barcodes that way or that regulations prevent real-time data syncing overseas. We don’t just lose weeks, you lose credibility and we all lose momentum which makes the 20 of us involved extremely demotivated.

In software, discovery is how you expose those blind spots before you invest the serious budget.

Here’s what a solid discovery process looks like when done professionally. It lasts usually over 2 to 6 weeks, depending on complexity and budget risk.

You start by stripping away assumptions until you can clearly answer two questions:

Example: if your plan is to “build a customer portal” discovery might reveal that your actual problem is increasing customer retention by reducing friction in renewals, which may not even require a fully custom portal. Sometimes the best solution is integrating with systems you already have.

Decision makers love to talk about software in terms of features. Discovery reframes the discussion around business outcomes.

This stage is where leaders often underestimate the return on investment. The insights you get from a handful of 30 minute conversations with real users can save hundreds of engineering hours later.

Example: A logistics company wanted a complex driver scheduling app. During discovery, user interviews revealed that drivers already used WhatsApp groups and only needed a way to automate shift confirmations. The “app” became a simple admin dashboard plus WhatsApp integration. This achieved one-third of the cost and twice the adoption, neat!

You’re not researching for curiosity or to burn the budget pretending that you’re working, you’re doing it to ensure that when engineers start coding, every feature has a user proven reason to exist.

Here the team visualizes how things actually work today. You zoom out to see every step, bottleneck and dependency. Then you zoom in to decide which parts are worth solving first.

Think of this like peeling an orange. For example:

By this point, you’re no longer drafting specs, but you’re identifying return on effort.

Now the team turns insights into tangible solutions like low‑fidelity prototypes, workflow mockups and architectural sketches. These are fast, disposable representations of ideas meant to test assumptions.

In leadership terms this is where you can begin to ask, “If we built this, how would we measure its success?”. Discovery enables data driven decision making before you’ve spent real development money.

Here’s where discipline meets ambition. The goal isn’t to design your five year vision, it’s to define the first high leverage version of it, commonly known as the "MVP".

You answer questions like:

This is the foundation of realistic roadmapping that’s separating functionality from mission critical launch scope.

Every executive knows that risk never disappears, but it only moves somewhere else.

Discovery forces you to map where it lives: technical complexity, regulatory exposure, third‑party integrations or team capacity. Once those are visible, you can address them proactively rather than reactively. That’s the difference between a project that adjusts course mid flight and one that crashes quietly in quarter three.

Unlike coding work, discovery is purely exploratory, but that doesn’t mean it’s unestimable. You estimate it based on the surface area of the unknowns.

Here’s a simple matrix used by software consultancies:

The deliverables are predictable: workshop findings, user insights, a documented MVP scope, preliminary architecture notes and a lean roadmap with draft effort estimates.

For leaders, this is a huge win since it caps your uncertainty cost. You’re not committing six figures, but you’re investing a fixed, modest amount to reveal whether the six figure build even makes sense.

Only after discovery. Because only then do you have:

After that, your partner can produce tiered estimates:

This layered estimation method gives teams predictability without forcing premature commitments.

Example: After a two week discovery, a mid‑size e‑commerce client learned that integrating a third party order management system instead of building one from scratch reduced their total build cost by 40%. No engineer touched a line of code. Can we conclude then that discovery paid for itself five times already before development began?

It’s worth restating because this is where projects live or die.

Skipping discovery is not skipping cost, but trading small, predictable costs for large, chaotic ones later.

As a decision maker, your job is not just to pick a vendor or sign off on scope. It’s to create the conditions where good software can succeed.

That means:

Discovery isn’t overhead, but a strategic risk management. It ensures that when you estimate, you’re estimating reality, not an idea still covered in question marks.

Client A: skipped discovery to “save time.” They requested a “custom CRM for sales automation” and pushed straight into building. Four months later, leadership realized that marketing didn’t use the same data definitions, compliance log policies blocked half the intended functionality and sales adoption was near zero. The rebuild cost was double.

Client B: invested two weeks in discovery before writing any code. They discovered that their biggest friction wasn’t about CRM, but customer onboarding delays. They built a lightweight onboarding dashboard integrated with existing systems. Costs dropped by half, revenue retention improved by 14% and they had buy‑in from every department by launch.

Both spent money on software. Only one spent it wisely.

Discovery doesn’t guarantee success since nothing in software does, but skipping it almost guarantees you’ll pay for avoidable mistakes later.

If you take just one principle from this: Estimate only after you’ve discovered and estimate discovery first.

That’s what separates accidental projects from strategic ones, the ones that continue to generate value long after the code ships.

If you want to read more articles like this, you can do so here: https://code-of-us.beehiiv.com