You have a platform to build and a budget of $5k or more. You can start in one of two ways. Send a brief to three agencies and have quotes this week. Or pay for 1–2 weeks of discovery first and get a fixed estimate at the end of it.
The quote is faster and free. It is also priced on guesses: about your roles, your integrations, what happens when a payment fails. Every guess that turns out wrong comes back later as a change request, usually in the middle of the build, when changing course costs the most.
Discovery costs money up front. Ours starts from $1.5k, and the fee is credited in full if the build starts within 60 days. This post covers what a paid discovery phase should hand you, how much of your time it takes, how to tell a useful one from a padded one, and when you should skip it.
What a discovery phase should hand you
Discovery starts with workshops: working sessions where we walk through your users, your current process and the systems the product must talk to. The workshops are the input. What you pay for is what comes out of them.
A feature specification. Every feature written as who does what and what must be true when they finish. It includes the roles and what each may see, the failure cases (a declined card, an expired invitation, a supplier that does not answer) and a list of what is out of the first release.
An architecture. The main records the system stores and how they relate, every outside system with a note on whether it has a usable API, where money moves, and where the product will be hosted. A CTO should read this part closely. It is where most surprises are found or missed.
A clickable prototype. The main screens linked together so you can click through the key flows before anything is built. It is not the final design. Its job is to show you, your staff or a pilot customer what the product will do, so a misunderstanding costs an afternoon instead of a sprint.
A fixed estimate and a plan. One price for the scope in the specification, the order the work will happen in, and the milestones where you will see working software. It should also say what would change the price, so you know the rules before the first change request.
Your brief is what you bring in. If you have not written one yet, our guide on how to write a software brief covers the seven questions it should answer. Discovery turns that brief into something a team can build and price.
What it costs you in time
On the calendar, 1–2 weeks. A product with one user type and one payment flow sits at the short end. Several roles, outside suppliers or two languages push it to the long end.
The money is the smaller part of the cost. The bigger part is your attention. During those weeks you need to attend the workshops, answer questions within a day and make decisions when they come up. Two people should be in the room: the person who owns the budget, and someone who does the work the product will replace. The second person knows the exceptions nobody wrote down.
If every decision waits a week for a meeting, a 2-week discovery becomes a 5-week one. Block the time before you start.
How to judge a discovery phase
Whoever runs it, you should be able to check the output against a simple standard. Use this table on any agency's discovery before you pay for it.
| Deliverable | What good looks like | Red flag |
|---|---|---|
| Feature specification | Each feature names a user, an action and a finish condition; an out-of-scope list | A list of feature names with no rules behind them |
| Failure cases | Written rules for failed payments, refunds, expired access, missing data | Only the path where everything works |
| Architecture | Every outside system named, with whether its API was checked | A slide of technology logos |
| Prototype | You can click through the main flows, including an error screen | Static pictures of the home page |
| Estimate | One fixed number tied to the specification, with what would change it | A wide range, or a number with no scope attached |
| Plan | Milestones, each ending in something you can use | "Phase 1: development" |
| Ownership | The documents are yours in writing, in formats you can open | Files that only make sense inside the agency's tools |
One practical test: give the specification to a second team and ask for a quote. If they can price it without a long call, the specification is doing its job. If they need to start from zero, you paid for meeting notes.
Also ask before you sign what happens to the fee if you decide not to build, or to build with someone else. The answer tells you whether the discovery is a product or a sales step.
When to skip discovery
Discovery is not always the right first step, including with us.
You already have a specification and a prototype. If earlier work produced both, and they are current, ask for an estimate against them instead of paying to redo them.
The job is a Laravel upgrade. The scope there comes from the code, not from workshops. We start with a free upgrade check: you share your
composer.lockand we tell you how far behind you are. Upgrades start from $1k.Nobody has paid for the idea yet. A no-code tool or a template can test demand for less than a custom build. Our post on MVP vs. full product covers when launching small is the better call.
You cannot start the build within 60 days. The discovery is still useful, but you pay for it outright, and a specification that sits for six months goes stale as your business changes. Run it when you can act on it.
What goes wrong without one
The problems are rarely dramatic. They arrive one at a time. For example, take a B2B portal for a distributor with a few dozen customer accounts, quoted from a two-page brief.
In the first weeks the build goes well. Then someone mentions that prices differ per customer and live in the ERP. The ERP has no API, so the team needs a nightly file import, which nobody priced. Next, it turns out a customer account has buyers and approvers, and approvers see different screens. Then the first payment fails in testing and nobody agreed on what the customer should see.
Each of these is a question that was never asked. On a fixed-price contract, each becomes a change request and a negotiation. On time and materials, each becomes a bigger invoice. Our post on fixed price vs. time and materials covers how each model handles this. Discovery moves these questions to week one, when answering them costs a conversation.
What a known scope looks like at build size
Marafiq is a training platform for facilities-management professionals. Two developers built it in about three and a half months, from May to August 2026. It runs exam-prep courses with live Zoom cohorts and recorded Vimeo lessons, timed quizzes graded automatically, PDF certificates with a serial number, QR code and public verification page, a cart with coupons, and card and installment checkout through Stripe and Tamara. It is Arabic first, with English.
It has about 940 automated tests, 1,700+ learner accounts and 25 published courses. The Marafiq case study has the details.
Look at that feature list as a specification would. Each item hides rules: what happens when a quiz timer runs out mid-answer, when an installment plan is declined, when someone checks a certificate that was revoked. A build of that size keeps a 3.5-month timeline only when those rules are settled early. Writing them down is the work discovery does.
How our discovery sprint works
Our sprint takes 1–2 weeks, starts from $1.5k and hands over the four deliverables above. Platform builds start from $5k.
You contract with our US LLC in Illinois and pay in USD. Workshops and calls run Monday to Friday, 9 am to 1 pm Eastern. If your project is smaller than a platform build, or you need a team inside your company for years, we will say so on the first call. Our post on what a SaaS build costs lists the factors we will ask you about.
Bring your brief, or just the problem and the systems involved, to an intro call. We will tell you whether discovery makes sense for your project or whether you can go straight to an estimate. Book an intro call.