Start with one person and one job.
Many first products go wrong in the planning, long before anyone writes code. Here is what to work out, what to bring to a first conversation, and what can safely wait.
Say you run a tutoring business and parents keep asking on WhatsApp which sessions their child attended and what was covered. You start picturing an app: logins, a dashboard, reports, payments, a chat screen. Before any of that, answer a smaller question. Who opens this product first, and what do they need to get done when they do?
You don't need a specification document to answer it. A plain account of the problem is worth more: who has it, how they deal with it today, and the point where that way of working breaks down. Specifications written before anyone has looked closely at the real process tend to describe a product that was never checked against the work.
The most useful preparation is to follow one real case from start to finish. Take an actual parent enquiry or order from last week and note every message, spreadsheet, phone call and tool it touched. That single trace usually shows the shape of a first version better than a long feature wishlist.
Work it out in this order.
Name the first user
Avoid “customers” or “staff” in general. Pick the one group whose problem the first release has to solve, such as the parent checking attendance or the coordinator assigning tutors. Other groups can follow once the first one is well served.
Map today's process, awkward parts included
Write down what actually happens, including the workarounds people would rather not mention: the copy-paste between sheets, the reminder sent from someone's personal phone, the step only one person knows how to do. Those awkward parts are often where software earns its place.
Describe the first result
Finish the sentence “When the first release is live, a parent can…”. Describe what someone can do, and leave screens out of it. If the sentence needs several “and”s, the first release is probably too big.
Separate what you know from what you're guessing
Keep a short list of assumptions beside the plan. Will parents log in at all, or would they rather get a weekly message? Will anyone pay for this? Does your current scheduling tool let other software read from it? Each open question should either shape discovery or be tested by the first release.
You don't have to decide these yet.
The technology
There's no need to pick a language, framework or cloud provider. The product's needs and constraints should drive that choice, and a good team will explain its reasoning in plain terms.
Finished designs
Bring any sketches, screenshots or examples from other products you like. If you have none, real examples of the work and the steps a user takes are a better starting point than a mock-up drawn without them.
Every feature for the next few years
Keep a parking list for ideas as they come up. Writing them down means they aren't lost, and it keeps them out of the first scope at the same time.
App, website or messages
Whether the first release lives in a browser, on a phone or inside a messaging channel depends on where your users already spend their time. Discovery is the right place to settle it.
Bring these to the first call.
- One real case traced end to end, with the messages, files and tools it passed through
- Screenshots of the spreadsheets or software in use today
- Any sketches or designs, however rough
- Fixed points: a date that matters, systems you must keep, a spending limit
- Who on your side will make decisions and review the work
- Names of the tools the new product may need to connect to
What founders ask at this stage.
How detailed does my brief need to be?
A page is plenty. The detail that matters comes out when we walk through the work together during discovery, which Aditya leads.
Should I build a prototype first?
Sometimes. If the big question is whether people will use or pay for the idea, a narrow first release or a clickable prototype can answer it with far less work than a full product. MVP development covers how we scope that kind of release.
What if I'm not sure the idea is worth building at all?
Say so at the start. Discovery can end with a recommendation to test the idea another way, use an existing tool, or wait. If a ready-made product might do the job, our guide on custom or ready-made software helps you compare.
Once the brief is written.
Got a rough brief? Send it over.
Share what you have, however unfinished, and we'll reply within one to two business days.