The short answer
Why this is the front door
If you are about to hire a team to build a product, the first useful question is not "how much?" It is "what, exactly, are we building, and what would have to be true for that number to hold?"
Paid discovery is how you answer that without starting the build on a handshake. I treat it as the front door of a custom engagement.
This is not a second fractional CTO cost guide. Advisory retainers and custom builds are priced differently.
What you are paying for
A useful discovery is work, not a workshop with a sales deck.
Someone has to sit with the people who will use the product, write down the current workflow, and name the constraints: systems you already have, data you have to keep, compliance you cannot skip, and the date that actually matters.
The point is to turn a vague brief into a scope a builder can be held to. That includes the hard parts, the things a free proposal usually leaves as "to be confirmed."
You should expect, at a minimum:
- A written description of the problem and the user.
- A v1 that is small enough to ship, with a clear out-of-scope list.
- The integrations and data migrations that will affect the build.
- The main technical and delivery risks, named in plain language.
- A build quote that is tied to that scope, not to a generic package name.
What you walk away with
The output should be yours. You can take the scope to our team, to another team, or you can wait.
That is the difference between paid discovery and a free sales process. In a sales process, the vendor keeps the thinking and you keep a pitch. In a real discovery, you leave with a document you can use even if you never sign a build contract.
I will also tell you when the right next step is not a custom build. Sometimes the answer is to buy or configure an existing product. I wrote about that choice in Build vs buy software. Discovery that cannot reach that conclusion is not independent enough.
Why the build should not start with a guess
I have been brought into stuck builds more often than I would like. The pattern is familiar. The founder and the vendor agreed a start date, and they never agreed what "done" meant. Integrations appeared later. The first demo looked fine and the second month was spent arguing about what was in the quote.
Starting a custom build before discovery is how that happens. The team has to invent the product as they code it, and you only see the mismatch when you are already paying for it.
That is why a custom build starts with a paid discovery. A vetted partner engineering team, run by a Kompella product lead, does the work that follows. Architecture choices and production decisions stay with me. Once the scope exists, the build is scoped and quoted on a call.
You can see how that sits next to our Build & Ship work, and how we run an engagement on How we work. If you also want standing technical leadership around the build, that is the fractional CTO service, which I define in What is a fractional CTO?.
Book a call to see if discovery is the right next step
If you have a product in mind and you are not ready to sign a build, book a scoping call. Bring the brief you have, even if it is rough, and the systems you already depend on. We will tell you what a paid discovery should produce in your case, and whether you should build at all.
