This is the brief we ask clients to fill in before the intro call. Plan on 20 to 30 minutes. It does not need to be polished, and “I don’t know yet” is a perfectly good answer.
Short sentences beat long ones. If a section runs past a few lines, you are probably describing the solution before the problem is clear.
The brief is not a contract and nobody grades it. Its job is to get the useful facts onto one page, so the first conversation starts from your situation instead of from a list of generic questions. Gaps are fine, because spotting them early is the point.
#The template
Copy everything in the block below into a document and replace each bracketed prompt with your answer.
ONE-PAGE PROJECT BRIEF Your name and company:Date: 1. The problem (two sentences)[What is broken, slow or missing today? What does it cost you?] 2. Who uses it, and what they do today[List each type of user. For each: what do they do now, and with which tools?] 3. Must-haves[What must work on day one, or the project is not worth doing? Aim for 3 to 7.] 4. Nice-to-haves[Useful, but you can live without them at launch.] 5. Out of scope[What this project will not do. Be blunt.] 6. Systems and data it touches[Tools, spreadsheets, accounts and databases, and who maintains each. Flag anything sensitive.] 7. What success looks like (plain words)[Three months after launch, what is different? How would you notice?] 8. Deadline[A date, and what is driving it. Say "flexible" if it is.] 9. Budget range[A range is fine. It tells us which options are realistic.] 10. Who decides[Who approves scope and price? Who else must be consulted?]#How to fill it in
- Describe the problem, not the tool. “Quotes take two days to go out” is more useful than “we need an app.”
- Name real users. “The front desk” and “our two estimators” beat “staff.” Different users often need different screens.
- Keep must-haves short. If everything is a must-have, nothing is. Move the rest to nice-to-haves.
- Be generous with out of scope. Naming what you are not doing early prevents the most common misunderstanding later.
- Write success as something you could observe. “Nobody retypes orders into the accounting tool” can be checked. “Better efficiency” cannot.
- List the systems you already use. Include the boring ones: the shared spreadsheet, the email inbox, the accounting tool. New software usually has to read from or write to them.
- Give a budget range. You are not locking anything in. A range lets an engineer suggest options that fit instead of guessing.
#What happens next
Send the brief before the call. The engineer who joins the call reads it first, so the 30 minutes go to your questions and the gaps, not to basics.
If a section stumps you, leave it blank and say so. We would rather talk through an honest gap than read a confident guess.
From there, discovery turns the brief into a written scope with a fixed price. If you want help getting the wording right, read how to write a brief a developer can quote.
Ready to go? Book a 30-minute call and email it to hello@altamar.dev.
