The product build checklist.
Every question worth asking before, during, and after a product build. This is the working list we run with our own clients, published in full. Use it with any team, including us.
01
Before you spend any money
The cheapest mistakes are the ones caught before a contract is signed. Every item here costs a conversation, not an invoice, and any one of them can save you a quarter of wasted build. If you cannot answer something on this list, that is not a failure. It is the work to do first.
- Name the single user the first version serves. One kind of person, described specifically, not a market segment.
- Write the one journey that must work: what this person does, from opening the product to getting the value.
- Name the riskiest assumption in the plan, the one that sinks the idea if it is false.
- Check what already exists: the competitor, the spreadsheet, the manual process this replaces. Understand why people tolerate it.
- Try to sell it before it exists. A signed letter of intent, a deposit, or ten honest conversations beat any survey.
- Set the real budget, including your own attention. A build needs decisions from you every week.
- Decide who on your side can say yes. A project where every decision needs a committee moves at committee speed.
- Write one page: what it does, who uses it, what it talks to, and the constraints. Send the same page to every team you evaluate.
02
Scoping the first version
Scope is the only lever that cuts cost without cutting quality. The goal of a first version is to get the core value into real hands quickly, and everything on this list serves that.
- Cut to one user type. Every audience you add brings its own screens, permissions, and edge cases.
- Write the cut list down: every deferred feature, with a sentence on why it can wait. Keep it visible.
- Mark what a human can do by hand for the first months: onboarding, support, reporting, billing exceptions.
- Count the integrations honestly. Every external system the product talks to is real work, and old ones are more.
- Separate day one from month three. Most features argued about at scoping never matter until there are users.
- Flag compliance early. Health data, payments, and data about minors change the engineering, and retrofitting is expensive.
- Agree what done means for the first version: a launch test you can pass or fail, not a feeling.
03
Choosing who builds it
We wrote a full guide on this, but the short version fits in a checklist. These items work against any studio, agency, or freelancer, and they work against us.
- Ask for products that are live right now, with real users, and how long they have been running.
- Talk to one past client you pick from their case list, not the reference they offer.
- Ask who exactly will do the work, and whether the people in the sales call appear in the code.
- Expect pushback on your scope. A team that tries to make your first version smaller is the best signal in the industry.
- Get a written proposal: scope, timeline, price, and how changes are handled. No number in writing, no deal.
- Confirm in the contract that code, designs, accounts, and documentation are yours from day one.
- Ask what happens if you leave halfway. The right answer: you keep everything, pay for work done, and they help hand over.
04
During the build
Most failed projects fail quietly, in the weeks nobody was watching. The defence is a rhythm where working software is seen often and decisions are made in the open.
- Attend a weekly demo of running software. Not a status call. If there is nothing to click, ask why.
- Keep a decision log: what was decided, when, and why. It costs minutes and saves arguments.
- Get access to a staging environment you can open any time, on your own devices.
- Insist changes are priced and approved before they are built, never surfaced on an invoice.
- Watch the unglamorous work get done: error handling, monitoring, the admin tools support will need.
- Make sure documentation is written as decisions happen, not promised for the final week.
05
Before you launch
Launches rarely fail on the feature everyone worried about. They fail on the path nobody walked end to end. Walk it.
- Run the core journey on real devices and real networks, including a cheap phone on a weak connection.
- Test the payment path with real money, including refunds and the failure cases.
- Confirm monitoring and alerting are live, and that someone specific gets woken up.
- Read every error message a user can see. Each one should be written by a human, for a human.
- Have a rollback plan you have actually rehearsed, not just described.
- Set up the support channel and decide who answers it in week one.
- Check the legal basics: privacy policy, terms, and whatever your domain requires.
- Verify analytics capture the launch test you agreed at scoping, so the launch produces an answer.
06
After launch
The launch is where the real information starts arriving. The teams that win the second quarter are the ones that treat the first month as the most important research they will ever do.
- Watch real behaviour daily for the first two weeks. Where people stall is your real roadmap.
- Talk to actual users, live. Five conversations beat any dashboard.
- Set a triage rhythm for bugs and feedback, so nothing important ages silently.
- Budget for maintenance from month one. Dependencies, platforms, and real usage all generate work.
- Reorder the roadmap by evidence, not by the plan you wrote before you knew anything.
- Decide who owns the product now: your team, the build team, or a handover between them, on purpose.
Want a second pair of eyes on your plan?
Bring the checklist with your answers filled in. We will tell you what looks solid and what looks risky, and the conversation costs nothing.