What a paid discovery actually buys you

Every software project starts with a moment of maximum confidence and minimum information. The idea is clear in your head, the demo you imagine is beautiful, and every developer you talk to says some version of "sure, we can build that." Then you ask what it will cost, and the answers range from suspiciously cheap to mildly offensive, with nothing to compare them against. Our answer to that moment is a paid discovery. This article explains exactly what you get for the money, so you can decide whether it is worth it, with us or with anyone else.

Why paid, and why first

A free estimate is a guess wearing a suit. Nobody can price a system they have not examined, so a free quote is priced to win the deal, and the difference between the quote and reality gets negotiated later, when you have the least leverage. A paid discovery flips that. You pay a fixed, known price for a couple of weeks of real work, and in return every promise that follows is grounded in something. If the numbers that come out of it scare you, you have spent a fraction of the project to find out, and that is the cheapest scare available in software.

Here's the honest picture: discovery is also protection for us. We commit to fixed milestones once we know what we are building. We can only do that because the thinking happened first, on paper, where changing your mind costs a conversation instead of a rebuild.

The documents you walk away with

Discovery produces documents, and the documents are yours. Not a slide deck of enthusiasm. Working papers that another team could pick up and build from, because that is the test we hold them to.

What actually happens during those weeks

Mostly, questions. Alexandru runs the sessions personally, and the sessions are work: walking through how your business runs today, where the money moves, what happens when things go wrong, who touches the system and what they must never be able to touch. We write while we talk. Every session ends with "so to confirm:" followed by a list, because a requirement you have not read back to the person who gave it is a rumor, and rumors are expensive to build.

In parallel, we test the risky assumptions. If your product depends on a third-party integration, we confirm the integration actually exposes what you need before the plan relies on it. If there is an existing codebase, we read it. The point of discovery is that surprises happen now, in the cheap phase, on purpose.

The estimate you can hold someone to

The roadmap that closes a discovery names milestones, and each milestone names a price and a delivery you can see and touch. That phrasing matters. A milestone that ends in "backend progress" cannot be verified by anyone who does not read code. A milestone that ends in "your operators can log in, see live vehicle positions, and export the weekly report" can be checked by you, in your browser, in a minute. Estimates built from verifiable milestones stay honest, because everyone can see when they stop being true.

What if you take the documents elsewhere?

Then the discovery did its job. The deliverables are written to survive without us: any competent team can build from them, and a good one will thank you for showing up with real requirements instead of a feeling. We would rather lose a build to a well-prepared client than win one against a confused one.

When discovery is the wrong tool

So to confirm: not every project needs this. If your scope is genuinely tiny, a fixed-scope build with a short written brief is enough, and we will tell you so on the intro call rather than sell you two weeks of ceremony. Discovery earns its price when the project is big enough that a wrong guess costs months, when a stalled codebase needs a verdict, or when you need numbers solid enough to raise money or approve a budget against.

The discovery phase, step by step →

Writing requirements an engineer can build from →