A developer can only give you a fixed price if the work is written down clearly enough to be priced. When it is not, you get a range, and the range gets resolved later by whoever has less say in the conversation, usually you.
This guide walks through what to write before you talk to anyone. It takes an afternoon, and it works whether you hire us or someone else.
#Start with the problem and who has it
Write two or three sentences: who has the problem, what they are trying to get done, and what goes wrong today. Name real roles, not “the business.” For example: “Dispatchers re-type every job from email into a spreadsheet, and drivers call to ask what changed.”
Avoid describing a solution here. “We need an app” is a solution. “Drivers cannot see their day without calling the office” is a problem, and it leaves room for a better answer than the one you had in mind.
#Map the current process
Write the process as it actually runs, not as the manual says. For each step, note four things:
- What happens (one verb and one object)
- Who does it
- How long it takes, roughly
- Where it breaks: missed handoffs, retyping, waiting, errors someone has to fix later
The “where it breaks” column is the most valuable part of the page. It tells a developer where the work is. If you want a ready-made layout, use the process mapping sheet.
#List the systems and data involved
Write down every tool the process touches: spreadsheets, email, accounting software, a CRM, a website, a phone system. For each one, note what data lives there and whether the new system needs to read it, write to it, or replace it.
Also note how much data exists. A few hundred rows and ten years of records are very different migrations. If some of it is messy (duplicates, free-text fields, inconsistent names), say so now.
#Separate must-haves from later
Make two lists. The must-haves are the things without which the build is pointless. Everything else goes under “later.”
A useful test: if the first version launched without this feature, could people still do their job? If yes, it is a later item. Be strict, because every must-have is priced and every “later” item can be quoted separately once the first version is running.
#Say what is out of scope
Write a short list of things the build will not do. Out-of-scope items prevent the most common scope dispute: one side assumed it was included and the other did not. Typical entries are “no public customer login,” “no migration of records older than 2020,” or “no changes to the accounting system.”
If you are unsure whether something belongs on this list, put it there and let the developer ask you about it.
#State your constraints
Constraints shape the price as much as features do. Write down:
- Deadline: a real date and the reason behind it (a season, a contract, a hire starting)
- Budget range: a number or a band, even a rough one. It lets the developer propose what fits instead of guessing
- Languages: which languages the users and the screens need, English, Spanish or both
- Compliance and privacy: any rules about customer data, payments, health records or where data may be stored
- People: who will use it, how many, and on which devices
#Decide how you will know it worked
Pick two or three measures before the build starts, while nobody is emotionally attached to the result. They should be things you can observe: the number of manual re-entries per day, how long a quote takes to send, how many calls go unanswered.
Write the starting number now, even if it is an estimate. Without a baseline, “it worked” turns into an opinion.
#Put it on one page
Everything above can fit on a single sheet. If you want a template, the one-page project brief has a section for each item here. Send it before the first call, and expect better questions and a firmer number in return.
If something on your page is still vague, that is fine. Flag it as an open question. A good discovery workshop exists to close exactly those gaps, and a written list of open questions is much cheaper to resolve than a surprise halfway through the build.
