Discovery

The phase consists of four blocks. Business context: what problem the product solves, how the company earns today, which metrics have to move. Users: who they are, what their scenarios look like and where the pain sits now, established through interviews with real people rather than the team’s idea of them. Constraints: integrations with existing systems, data requirements, the budget frame, deadlines, regulatory obligations. Solution: product structure, prototypes of the key screens, an architecture sketch and a risk list.

The economics are direct. Discovery typically consumes 5-10% of the project budget and is the cheapest point at which a decision can still be changed. After it the scope becomes estimable: the range narrows from "somewhere between 500,000 and two million" to a spread of 20-30%, because the screens, integrations and data volumes are known. A regular side effect is scope reduction, as features that looked mandatory move to a later phase or disappear once real users have been interviewed.

One organisational point matters: discovery is paid for separately and the output belongs to the client. That protects against lock-in, because with a finished specification, prototype and estimate you can run a tender and compare contractors on one document rather than on presentation quality. A contractor who refuses to hand over the materials, or who does the phase free "against the future project", is effectively selling you dependency. The reverse is equally honest: free pre-project analysis nearly always means estimating by analogy and a later round of "we did not account for that".

It is worth saying when discovery is not needed. A standard landing page, a small site with an obvious structure, an extension to an existing system within known bounds: a separate research phase there eats budget without returning anything, and a brief plus a prototype is enough. It earns its place where unknowns are numerous: a new product, complex internal processes, integrations with accounting systems, several user roles, regulatory requirements. A simple test is whether you can list the screens of the future system in five minutes; if not, discovery pays back.

Related terms

• Technical specificationA technical specification is the document that fixes what exactly will be built and on what grounds the work counts as accepted: goals, roles, scenarios, screen-level requirements, integrations, non-functional requirements and an explicit out-of-scope section.
• WireframeA wireframe is a rough screen schematic without colour, typography or imagery: it fixes which blocks exist, their priority and the transitions between screens, so the interface logic is agreed before expensive visual design starts.
• MVPAn MVP is the first release of a product that carries exactly one user journey end to end, shipped in four to eight weeks so the demand hypothesis gets tested against real users and real payments rather than survey answers.
• Fixed price vs time and materialsFixed price and time and materials are two contract models: the first fixes scope, deadline and price with the risk premium sitting on the contractor, while the second pays for hours actually worked at an agreed rate and leaves scope control with the client.
• Usability testingUsability testing is checking an interface with real people: participants from the target audience carry out realistic tasks while thinking aloud, and the team records where they stall, where they go wrong and what they fail to find.

Related services

• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
• UX/UI design for websites and appsWe design interfaces that survive contact with production: research, structure, UI kit and a clean handoff to the developers. Everything lives in Figma as components with real states and real breakpoints, not as a folder of flat mockups. The same process covers landing pages, corporate sites, e-commerce, web apps and mobile.
• Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.

Read more

• The Technical Specification: Structure, a Worked Template and the Usual MistakesA specification is not bureaucracy, it is leverage: anything that does not match it gets fixed by the vendor at no charge. Here is the section structure, a filled-in example for a corporate site and how to write acceptance criteria somebody can actually test.
• MVP in 2026: Real Timelines, Real Budgets and What to CutMVP no longer means cheap and rough. A weak prototype today produces a false negative and buries a workable idea. Here are four MVP tiers with prices and timelines, a framework for cutting scope, and the parts no budget justifies removing.
• How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.