Product discovery before building an application

Discovery is the pre-build phase in which the problem, users, intended outcome, scope boundaries, risks, and technical assumptions are agreed. Its outcome should be a document sufficient to compare options and prepare an estimate, at a level appropriate to the size of the project.

Discovery does not guarantee a lower project cost, but it reduces uncertainty. It exposes conflicting expectations, missing data, difficult integrations, or legal risk before they become dependencies for many finished features.

Why do it if I already know what I want to build?

Because a description of an idea may be understood differently by the buyer, user, and delivery team. Check three kinds of misalignment before the first line of code:

• Scope misalignment. An “admin panel” can mean three screens or thirty. Without agreeing which version is estimated, a dispute is only a matter of time.
• Problem misalignment. A client wants an application to manage jobs, while the real issue is that jobs arrive through five channels and nobody collects them. An application will not solve a problem it does not touch.
• User misalignment. The buyer and the user are often two different people with different needs. An application designed for the buyer can go unused by the team.

What happens during discovery?

1. Business goals, not a feature list

The first question is not “what should the application do?” but “what should change in the company when it works?” The answer becomes the criterion for cutting features later: if something does not serve that change, it falls out of the first version.

Useful answers are measurable: shorten job handling, stop re-entering data between systems, or give customers visibility without calling the office.

2. Users and their tasks

Who will use it, how often, on what device (desk or phone), and what exactly they are trying to achieve. Without this, an application can be logical to its designer and awkward for its user.

The most useful question here is: how is this done today? Even if the answer is a spreadsheet and three emails, it describes the process the solution needs to support.

3. The current and target process

Map today’s flow, marking where something gets lost, then describe the target version. At every step ask: “what do you do when the data does not match?” The answers define the real process — and they determine cost.

4. Data model

During discovery we agree the main concepts in the domain and their relationships. We do not design every table “just in case”, but we check that scope is not based on contradictory definitions. Changing core relationships later may require data migration and updates to many features.

5. Constraints and integrations

List systems to connect, legal requirements, personal data, external deadlines, and budget. A constraint can materially change the estimate — for example if a system does not expose the needed interface or a contract prohibits a particular way of processing data.

6. First-version scope

Separate “must exist for this to work at all” from “would be nice”, with a reason for each item. For a product with one key journey, the relevant benchmark may be our MVP in 4–6 weeks scope.

7. Risks stated plainly

Make a list of things that may go wrong and assess their impact. A project without written risks is not safer — you will simply discover them later and more expensively.

What should come out of it?

A concrete document, not meeting notes. Ours includes:

• a problem statement and measurable goals;
• users and their tasks;
• the target process;
• the data model and solution architecture;
• first-version scope plus a list of consciously deferred items;
• phased schedule and estimate;
• risks with a response plan.

This document is yours and can be delivered with us or anyone else. If you commission the build from us, we deduct the discovery fee from the project estimate. We explain later stages in how to build an application from scratch.

How much does it cost and how long does it take?

Our ranges as of August 2026: a discovery workshop with a direction document 3,000–8,000 PLN net, or full solution design and planning with architecture, roadmap, and estimates 8,000–25,000 PLN net. Time depends on the number of stakeholders and integrations and the availability of materials; it usually ranges from one workshop to around two weeks.

An estimate for a project described in one paragraph contains more assumptions and risk on both sides. A written scope makes clear what is included, what data the client must supply, and what triggers a re-estimate. Discovery can reduce the uncertainty buffer, but it can also reveal a requirement that raises the honest price.

When discovery is not needed

We are candid about this because we do not want to sell an unnecessary stage:

• When scope is genuinely small and unambiguous. One integration, one screen, one flow — discovery is excessive ceremony.
• When you have a good specification ready. It happens, especially if someone technical is on your side. A review is enough then.
• When the issue is validating an idea, not its scope. First check whether anyone wants it, even manually and without an application. Discovery makes sense once the problem is known to be real.

How to prepare on your side

Four things make the workshop faster and cheaper:

1. Collect real examples — actual jobs, documents, emails, and sheets you use.
2. Invite the person who does the work, not only the person who orders it.
3. List what cannot be done today even though it should be.
4. Decide who makes scope decisions. An unavailable decision-maker is a common cause of stoppages and conflicting agreements.

Frequently asked questions

Can discovery be done remotely?

Yes, and that is how we usually do it: a 2–3-hour online workshop, work on our side, and then a round of follow-up questions.

Do we have to commission the build from you after discovery?

No. The document is yours and commits you to nothing. If we continue, we deduct the fee from the project under the offer terms.

How is this different from an AI audit?

An AI audit answers “where would AI pay off in our company?” Discovery answers “what exactly should we build and how?” Sometimes the audit comes before discovery.

---

We run our own projects through discovery → brief → plan → implementation, and used the same pipeline to rebuild this website. So we can show what our brief looks like rather than only talk about it. See design and planning or describe your idea.