What a discovery sprint actually produces
Troy J Crowe · October 2026 · 5 min read
"Discovery" sounds like the phase where a developer bills you for thinking. Fair suspicion. So here's exactly what mine is, what you get at the end, and why I charge for it.
The short version: $1,500 fixed, 5–8 business days, and at the end you have a written scope, screen sketches and a fixed price for the build. If the build starts within 60 days of me delivering those, the $1,500 comes off the build price in full.
Who needs it
Not everyone. A landing page, a straightforward business website or a single automation can usually be quoted from a good conversation. Discovery is for builds with moving parts: logins and roles, data coming in from somewhere, more than one integration, or a process that lives mostly in people's heads. In other words, CRMs, portals, internal tools and multi-system automation.
Without it, any price I gave you would be a guess. Guesses either come in high to cover the unknowns, or come in low and turn into change requests. Neither is good for you.
How the days go
The exact order shifts, but this is the shape of it.
Day 1: the walk-through. A call of an hour or two. You show me a real week: where work comes in, who touches it, where it gets stuck, what you do on Friday afternoon that you'd rather not. Screen-sharing your actual spreadsheet is ideal. I'll ask a lot of "and then what?"
Days 2–3: mapping. I write up the workflow as I understood it, list every type of user and what they need to see and do, and sketch the data: what a customer is, what a job is, how they relate. I look at the tools it has to talk to, read their API documentation, and note the limits. This is where surprises turn up, like an accounting tool that won't let you create a certain record over its API.
Day 4: questions. You get a list of questions, usually by email, sometimes a short call. Things like "can a job have two technicians?" or "who's allowed to change a price after the quote's sent?" Small answers, big consequences.
Days 5–6: sketches. Rough screen sketches of the main views. Not polished designs; boxes, labels and real-looking data, so there's something to point at and say "no, the date goes there".
Days 7–8: the scope and the price. Everything gets written into one document, with a fixed price and a timeline. Then I walk you through it on a call.
On smaller systems this all fits into five business days. On larger ones, eight. Your response time matters too; quick answers to the day 4 questions keep it short.
What you get
At the end you'll have:
- A written scope: what the first version does, and just as importantly, what it doesn't
- User roles and permissions: who sees what, who can change what
- Screen sketches of the main views
- A data model outline in plain English
- An integration list, with the risks I found for each one
- A list of what I'll need from you during the build
- A fixed build price and a payment schedule
- A timeline estimate with milestones, including the midpoint review
- An out-of-scope list: good ideas agreed to wait for a later version
What the scope document looks like
A typical table of contents:
- Summary: the problem, in two paragraphs
- Users and roles
- Workflows, step by step
- Screens (with sketches)
- Data: the main records and how they connect
- Integrations: what syncs, in which direction, how often, and what happens on failure
- Migration: what data comes across, from where, and who checks it
- Out of scope for version one
- Assumptions and risks
- Price, payment schedule and timeline
It's written for a business owner, not a developer, though a developer could build from it.
Why it's paid
Because it's real work. Discovery that isn't charged for still gets paid for somewhere, usually inside the build price.
Charging for it also means you get a proper piece of work rather than a sales exercise, and I get a client who's serious enough to spend a week thinking about the problem with me.
Why it's credited
If you go ahead with the build within 60 days, the $1,500 comes off the build price in full. Discovery was the first part of the build all along; I'm not trying to make money twice on the same thinking.
The 60 days exist because things change. After a few months the scope may need revisiting, and my calendar may have moved on.
What if you don't build with me?
Then you keep the documents. They're yours. You can take the scope to another developer and ask them to quote it, and they'll be quoting the same thing I would have built, which makes the comparison fair.
Sometimes discovery ends with "you don't need a custom build; this off-the-shelf tool plus one automation would do". That's a good outcome too. It's cheaper to find that out in a week than three months into a build.
How to get the most out of it
- Bring the messy stuff. The spreadsheet with seventeen tabs is more useful than a tidy summary.
- Include the person who actually does the work, not only the person who manages it.
- Answer the day 4 questions quickly, even if the answer is "I don't know, what would you suggest?"
- Tell me about the exceptions. "Usually" is where software breaks.
If you're not sure whether your project needs discovery at all, ask on the intro call. Sometimes the answer is no.