Launch — Product Discovery
Product Discovery
Turn your idea into a build-ready roadmap — features defined, architecture mapped, costs estimated — before you commit a development budget. Discovery is the cheapest place in a project to be wrong.
Is this you?
Signs your idea needs a plan before code.
Most expensive software mistakes happen before the first line of code — in what got built, not how. Discovery finds them on paper, where they’re cheap to fix.
- The feature list changes every time you meet about it
- Developers quote wildly different numbers for the same idea
- Nobody can say for certain what belongs in v1
- Three stakeholders describe the product three different ways
- You’ve watched a budget burn on features nobody used
- You need real documents so the quotes you collect compare
What you get
Six documents a build team can quote against.
Concrete deliverables, not a deck of recommendations. Every one is written to be portable — build with us or hand them to any other team.
- Document01
Product requirements document
Every feature, user role and piece of business logic written down and signed off — so there’s one version of the product, not one per stakeholder.
- Roadmap02
Prioritized feature roadmap
v1, v2 and someday. Each feature ranked by impact and feasibility, then phased into releases so your first launch ships what matters and nothing else.
- Document03
Technical architecture plan
Stack, data model, integrations and infrastructure mapped before anyone writes code. The decisions that are expensive to change later get made on purpose, not by default.
- Flow map04
User flows & screen inventory
How each type of user moves through the product, step by step and edge cases included — plus a full screen list that shows the real size of the build.
- Document05
Competitive analysis
What alternatives already exist, what they do well and where the gap is that your product actually fills — so v1 is built to win, not just to exist.
- Estimate06
An honest estimate
Cost and timeline broken down feature by feature, by people who build software for a living. Line items you can question, not a single number to take on faith.
How it runs
From first interview to a costed roadmap.
Durations shown for a three-week discovery. A focused internal tool moves through the same steps in about one.
- 01Days 1–3
Interviews & goals
We talk to everyone who has a say in the product — founders, operators, the people who’ll use it — and write down the goals and constraints they actually agree on.
- 02Week 1
Requirements
Features, user roles, business logic and integrations captured in one requirements document. You sign off on it before anything else gets planned on top of it.
- 03Week 2
Priorities & flows
Every feature ranked by impact and feasibility and phased into releases, while core user journeys get mapped screen by screen. v1 gets lean on purpose, not by budget panic.
- 04Weeks 2–3
Architecture
Data model, stack choices and integration points planned by the engineers who would write the code, so the plan still holds up once a real build starts.
- 05Week 3
Estimate & roadmap
Everything rolls up into a costed, sequenced plan you can build against — with us or with any other team. The documents are yours outright.
The details
What a discovery engagement looks like.
- 01Who you’ll work with
Hunter May and Jake Gartenberg — our lead software engineer and lead design engineer, the same two people who would build the product. No account managers, no handoff to a junior team.
- 02Timeframe
One to three weeks, fixed scope. A focused internal tool sits at the short end; a multi-role platform with integrations takes longer. You know which before we start.
- 03What we need from you
- Time for stakeholder interviews in the first few days
- Access to the people who will use the product
- Any sketches, spreadsheets, docs or competitor notes you have
- Decisions when we bring you a tradeoff
- 04What happens after
The plan is yours. Build with us, since the people who scoped it would build it, or take it to any team and collect quotes you can finally compare. If we’re not the right builders, we’ll say why.
Honest fit
When discovery is worth it, and when it isn’t.
Discovery earns its keep while the product is still fuzzy. If you already have a spec your team trusts, skip ahead to the build.
A good fit if
- You’re building a new product and v1 isn’t defined yet
- You’ve collected quotes that can’t be compared to each other
- Several stakeholders need to agree before money is committed
- The product involves integrations, user roles or messy existing data
- You want a plan you could take to any team
Probably not a fit if
- You already have detailed requirements your team agrees on
- An existing tool already covers most of what you need
- A no-code tool could test the idea faster
- You want a slide deck of recommendations, not build documents
- You need a marketing site — web design includes its own planning
FAQ
Before you book discovery.
Something else on your mind? Ask us directly.
01What is product discovery?
It’s the phase before development where your idea becomes a build-ready plan. We define the requirements, prioritize the features, map the technical architecture and put an honest cost and timeline on the whole thing. By the end you know exactly what you’re building, in what order and roughly what it will take — before anyone writes code.
02Why not just start building?
Because changing a document costs nothing and changing built software costs weeks. Most budget blowouts trace back to decisions that were never actually made — features nobody agreed on, architecture nobody thought through. Discovery is the cheapest place in the entire project to be wrong.
03What deliverables do I actually get?
A requirements document covering every feature and user role, a prioritized roadmap that splits v1 from later releases, a technical architecture plan, mapped user flows and an honest cost and timeline estimate. Concrete documents a build team can execute against — not a slide deck of recommendations.
04How long does discovery take?
It’s a fixed-scope engagement, typically one to three weeks depending on the complexity of the product. A focused internal tool sits at the short end; a multi-role platform with integrations takes longer. Either way, you know the timeline before we start.
05Can I take the plan to a different development team?
Yes — it’s written to be portable on purpose. The requirements, architecture and roadmap are documented so any competent team can quote against them, which means the quotes you collect are finally comparable. That’s a big part of the point.
06Does discovery lock me into building with you?
No. Continuing with us is easy, because the people who scoped the product are the ones who’d build it — but there’s no obligation. And if we’re not the right builders for your project, we’ll tell you directly and explain why.
Related services
Services that pair well with this.
- Design PrototypeA clickable prototype real enough to test with users, show investors and hand to developers — before you commit a build budget.
- MVP DevelopmentFrom idea to a working product users can try — scoped tight, built fast on proven components, and ready to grow into the real thing.
- Custom Software DevelopmentInternal tools, customer portals and business platforms that replace spreadsheets and disconnected workflows — built to last and supported after launch.