Paid Discovery: A Concrete Decision Framework

How to start building your software without committing to a large budget.

Part 1: What is paid discovery?

You have a product idea or a business process you want to improve. But you do not yet know exactly what the software should include.

And, of course, you need to set a fixed budget. Everyone loves fixed budgets.

Here comes the trade-off: to estimate the budget, an agency may ask for detailed specifications. However, preparing them requires decisions you may not be ready to make.

The alternative is to start development on a time-and-materials basis. This gives you flexibility, but it can also leave the budget open-ended.

Paid discovery offers another starting point.

It is a short, focused project designed to answer the most important question before you invest in full development.

The question could be: What should you build first? Do users understand the idea? Is the product technically feasible? Which features bring the most value to the client?

Part 2: What is the right question?

Start with the greatest uncertainty

The first step depends on what you still need to learn.

• If you are unsure whether users will understand the product:

Create a clickable demo. Test the main user flow without building the underlying software.

• If you are unsure whether the technology will work:

Build a technical prototype. Test the integration, hardware connection, algorithm or another critical technical element.

• If you already have a vibe-coded prototype:

Review its architecture, security, data model and maintainability. Decide what can be kept and what needs to be rebuilt before it becomes a real product.

• If the product is clear but the full scope is too large:

Define the smallest usable release. Estimate that stage instead of trying to predict the cost of the entire product.

Part 3: The deliverables

What should paid discovery deliver?

Discovery should not end with a series of meetings and a presentation full of general recommendations.

Depending on the question, you should receive something concrete:

• A clickable and testable user flow that you can show to potential clients

• A technical feasibility result that proves the idea can be implemented

• A solid architecture that can be actually used as a basis for estimation and development

• A clearly defined or reduced scope and an estimate for the next stage

• A clear answer to the question defined at the start of discovery

The last point matters.

Sometimes the right decision after this stage is to continue.
Sometimes it is to change direction.
Sometimes it is to stop.

Discovering this early can save more money than immediately starting development.

Part 4: A practical example

A cybersecurity startup came to us with a vibe-coded prototype. The founders had technical experience, strong domain knowledge and access to potential customers. They had already used the prototype to validate several user flows and features.

However, the technical feasibility of the product was still unclear. Before presenting the prototype to a wider group of potential customers, the client wanted to know whether the idea could be developed into a real product.

We reviewed the prototype, defined the minimum viable feature set and designed an architecture to support it.

By the end of the discovery phase, we had confirmed that the product was technically feasible within the defined scope. The client also received a proposed architecture and a clear technical basis for the next stage. They could then use the prototype to collect wider market feedback and identify which features mattered most before investing in full development.