A discovery audit is one or two weeks of structured work before you hire a dev shop. It should end with a written scope, a budget range, and a clear go or no-go. Below is the checklist we use. You can run it yourself, or use it as the agenda for a short advisory engagement.
Most expensive build failures start before sprint one: nobody agreed who the buyer is, nobody picked a success number, and the backlog mixes version one with a wish list. Discovery is how you avoid paying twice. It isn't theater. It should produce decisions, and a demo script a skeptical buyer would understand. If you get a slide deck with no out-of-scope list, you paid for marketing.
Week 1: clarity and market story
- Ideal customer: company size, buyer's job title, the event that makes them look for help, and why now
- The job you replace: the current workflow, in the buyer's own words
- Alternatives: doing nothing, competitors, or building it themselves
- The promise: one main outcome you can prove in 30 to 90 days
- Proof you have today: pilots, a waitlist, signed letters of intent, usage numbers
- Non-goals: a written list of what version one will not do
- Messaging: a first draft of the homepage story, with the adjectives cut
If the team can't agree on the customer and the promise, pause engineering. That's budget control, not a slogan. Related reading: Clarity Before Execution and B2B positioning that converts.
Interview questions that get you real answers
Ask founders to role-play a sales call. What does the buyer say they hate about today's process? What do they risk by switching? If the answers are generic ("save time"), keep digging until you hear nouns: spreadsheets, invoices, roster rules, compliance letters.
Week 1: brand and website readiness
- A one-page positioning note: who you serve, what you do for them, why you're different
- Offer structure: product, service, or both
- Trust assets: case studies, a founder point of view, credentials
- Conversion path: one main call to action, a form or booking link, and someone who owns follow-up
- Channel reality: referrals only, or a real content and paid plan
Brand work at this stage isn't a logo refresh. The question is whether strangers can tell if you're for them. See brand and growth and the hidden cost of bad positioning.
Check the existing site against search intent
Look at your page titles and main headings. Do they match what buyers actually type into Google? Google's SEO Starter Guide is a good baseline for making pages findable and useful. It won't replace positioning, but it shows whether your future site can be found at all.
Also compare stack options in Webflow vs Next.js, so your marketing and product plans line up before you sign a build contract.
Week 2: technical discovery
- Current state: code health, hosting, test and live environments, where secrets are stored, how you'd know if something broke
- Rough architecture: what the website, the backend, scheduled jobs, and the database each do
- Logins and roles: who can see and do what, and how admin users differ from regular ones
- Integrations: which ones are must-have and which are nice-to-have, plus what the user sees when one fails
- Data: the main things your product tracks, and the ten questions people will ask of that data
- Performance and rules: speed targets, offline use, live features, compliance needs
- Delivery plan: milestones, a demo script, and what "done" means for v1
The output should be a buildable scope for engineering, not a 40-page deck nobody opens.
Questions that prevent surprises
Where do background tasks run? What happens when a partner's service times out? How is one customer's data kept separate from another's? What gets logged for support and compliance? Sketch the three workflows that matter most as simple step-by-step diagrams. Skip the edge cases for now.
If your product moves money or runs a marketplace, flag it early and read our marketplace MVP guide before anyone estimates.
Red flags
- "We need everything the competitor has" with no clear customer
- No founder available to make decisions during discovery
- Design is already done for a product nobody has specified
- A vendor quotes a price without asking about integrations or customer separation
- The success metric is "launch" instead of learning or revenue
One more: any vendor who refuses to write an out-of-scope list. That list protects both sides when priorities shift.
What you should walk away with
- A one-page positioning note and ideal customer profile
- A v1 scope with an explicit out-of-scope list
- An architecture sketch and a short risk list
- A timeline and budget band you can sanity-check against realistic MVP ranges
- A demo script and a success metric for the first release
How to use the risk list
Rank each risk by how bad it would be and how likely it is. Typical entries: a fragile integration, offline needs on mobile, a regulatory review, one person nobody can replace. Give each risk an owner and a plan (a short test build, a different vendor, or cutting the feature). Review the list every week during the build, not just at kickoff.
Who should be in the room
You want a founder or general manager who can decide, someone who talks to customers weekly, and a technical lead who will own the architecture. Not a rotating cast of advisors. A designer who thinks about workflow states helps too, as long as they aren't only producing marketing mockups.
After discovery, work out build vs brand sequencing so parallel work doesn't split your story in two.
Using the checklist to pick a studio
Ask every studio the same questions. How do you handle scope changes? Who joins the weekly check-in? Do brand and engineering share a lead? A quote that shows up before anyone has asked about integrations is an estimate, not a commitment.
If you already have an app in production
Discovery then has to cover migration: how to replace parts of the old system gradually, how to turn features on for a few users at a time, and how to move old data. A checklist built for a brand-new product misses the coupling that turns a "small MVP" into a six-month integration project.
Keep one living document
Use a single Notion page or wiki for your customer profile, scope, architecture diagram, open questions, and a log of decisions. Decks go stale. A living doc keeps new hires and vendors aligned while the founder is out selling.
Pick one number that matters
Before engineering estimates anything, agree on one main metric for v1. Examples: paid pilots, weekly active teams, time to first value, support tickets avoided. You can track secondary metrics, but the main one settles arguments about what to cut. If your stakeholders want five equal metrics, discovery isn't finished.
Short technical spikes
For each must-have third-party tool, spend two days on a spike. Connect to it, call one important endpoint, and handle one failure. You'll get a real effort number for the quote and you'll find blockers like sandbox access or legal review before sprint one.
End with a go or no-go
Close discovery with a decision: build now, build a smaller first slice, or stop and sell services until you have more proof. Discovery without a decision is just consulting. Put the decision in the same document as the scope, with the budget band, the timeline, and the one number that proves v1 worked.
Handing off to engineering
A good handoff includes user stories tied to the demo script, a clear list of what the backend must provide, and a ranked backlog with a visible cut line. Everything below it is "not v1." Engineers shouldn't have to guess scope from mockups. Every screen should map to a claim your business needs to prove.
FAQ
Know us a little more before you commit.
For serious zero-to-one work, one to two focused weeks. It can run longer when old systems are involved. Endless discovery with no decisions is just stalling, so set a date for the v1 scope decision and keep it.
Wireframes without a clear customer and architecture still lead to rework. Use them as input, not a substitute. They tell you which screens exist, not what claim you're trying to prove.
You should leave with a budget band and written assumptions. A fixed price is only safe when out-of-scope is explicit and you've agreed how changes get handled. Vague fixed quotes turn into change-order arguments.
That's a good result. Spend on positioning, pilot customers, or a narrower first slice, then rerun the technical part once the promise is sharp. Building anyway burns runway and morale.
If you'd like this audit run with you, not handed over as a PDF template, start a conversation. We'll tell you honestly whether you're ready to build.