You are about to commission a build. The screen is empty, the budget is approved, and nobody has opened an editor yet. This is the cheapest moment your product will ever have. Every question you answer now costs a short conversation. The same question, answered after the first deploy, costs a refactor, a migration, or a rebuild.
Developers fill gaps, because a gap still has to become a screen, a field or a saved record. Who owns the accounts. What is taken ready-made and what is written. Where a submitted request goes. What counts as accepted. Whoever answers by default is whoever wrote the code, and later you pay to change their answer. A sentence in a document is free to change. A saved record is not.
You do not need a fifty-page specification to avoid that. Six decisions, each written in a few lines, keep the first invoice close to the estimate. They are cheap while the screen is empty, and they are the expensive lines once code exists. Here they are, in the order they usually cost money.
1. What is taken ready-made and what is written
Part of the first release should not be written at all. Sign-in and password reset, email sending, payments, file storage, search: mainstream services do these already, and a wrong choice there costs a subscription you cancel. Write only what a customer could name as the reason they pay, plus the boundary between two customers. That is the criterion in one line: if a wrong choice is a cancelled subscription, take it ready-made; if a wrong choice is a rewrite of saved records, write it.
Every ready-made decision still gets a line of its own: what is taken, from whom, and what leaving it costs, meaning where the data sits and who can export it. Ten services nobody wrote down become a second project: the person who set them up leaves, and nobody can name what the product depends on to run at all. Keep that list on the same page as the rest of the decisions, where a new developer can read it without asking anyone.
The opposite mistake is writing commodity work to prove control. A hand-built payment form or a home-grown email queue is not a feature. It is a maintenance bill that starts in the second month, on a problem somebody else already solved and supports. The data questions behind these choices, who owns a row and what a second customer changes, are the neighbouring decision in choosing the stack for a new SaaS.
2. The accounts and the domain should be yours from day one
The domain, the hosting account, the cloud project, the payment provider, the email sender, the code repository. Register each of them under the company, with a company email and a card the company controls. This is an hour of work today. Without it you get a negotiation later, with a contractor who is busy, or a product that cannot be moved because the registrar account belongs to someone who has left.
Then decide how the developer gets access. A named invite to each service, revocable in one click, beats a password pasted into a chat. Write down who holds each account and who may remove access. If an account already sits in a personal name, move it before the build starts, not after the first argument about the bill.
One more thing belongs with the accounts: the money path. Name the payer on the payment provider and the person who may change the payout account. If sales run through an account in a personal name, the day that person leaves is the day revenue stops. Moving it is a form, not a project, but it has to be done before the first real payment arrives.
3. “Accepted” is a list of clicks, not a feeling
Before the first line is written, name five to ten checks that decide whether the work gets paid. Order one item. Change a price from a staff account. Send a test request and find it. Open the second language if you bought one. Each check must be runnable by someone who was not in the chats, with no explanation from you.
Write what acceptance does not include: a new logo, a perfect score from a tool nobody installed, copy written by the developer to fill a gap. A scope frozen in writing protects both sides, and the shape of that freeze is in how a written freeze protects both sides. Written now, these checks cost twenty minutes. Written after the build, they become an argument about what everybody obviously meant.
Keep the checks short enough that you will actually run them. Five good checks beat twenty that you skip. Put them in the same document as the scope, with a date on it. When the build arrives, run them in order and write down which one failed. A failed check points to a line. A feeling points to a rewrite.
4. Where the request must end up
A form that says thank you is not a finished feature. Decide where the submitted request lands: which mailbox, which CRM, which sheet, whose queue. Decide who sends the first reply and how fast. If the plan is to figure this out during launch week, the integration is unbilled work hiding inside your estimate.
Write the destination as a path, not a name. “Goes to sales” is not a destination. “A submitted form creates a card in the sales pipeline, stage New, assigned to the duty manager, with the phone number in the first field” is a destination. The developer can build that on day one and test it with one submission.
Walk one real example through before you accept the build. The whole failure path, from a form to a missing row, is written up in why a lead never arrives. A destination decided on day one is a few lines of configuration. The same destination, decided in month two, means reading every message that never arrived and rebuilding the flow around a tool the team already stopped opening.
5. Which environment can be tested in
Say now where the work gets tried before customers see it: a separate copy, a local install, a password-protected preview. Name who tests it and on which data. A copy with realistic data finds what an empty database hides: long names, duplicate emails, a customer with two addresses and one invoice.
If nobody decides this, the live site becomes the test environment by accident, and every check then happens in front of your customers. The reasons that goes wrong are in why you do not patch the live site quietly. Decide the environment before the build starts. Creating it is part of the work, not a delay to the work.
6. One person decides, and the noes are written down
Name the one person who answers for the product when two options both look fine. Not a committee, and not "we decide together". Where a choice has to be made and nobody owns it, the developer makes it by default, and that default quietly becomes the product. Later you pay to change an answer nobody remembers giving. The named person may be the owner, a product manager, or one founder. What matters is that everyone on the project can name them in one sentence.
Then decide how a "no" is recorded. A dated line, the option that was refused, and one line of reason, kept where the scope lives. Not a chat message, and not a meeting summary nobody opens twice. A short written list of noes is the cheapest defence against a scope that grows by friendly suggestion, and it is what you will reread in the second month, when someone proposes the feature that was already refused in the first week.
Also decide what a late "yes" costs. Adding something after the estimate is agreed is a new decision with a new date, not a small amendment, and the document should say so in one line. That single sentence is what keeps the first invoice close to the estimate, and it is worth more than any clause about hours.
Services cover planning a first version and reviewing a plan you already have, so the open questions close before the estimate is signed. Selected work shows the same six decisions next to a product that runs, not as a slide. If you are about to commission a build and want it planned before the first line, start with product development from scratch, or write to me with what the first version includes and what it deliberately does not. Passwords and customer data do not belong in a first message.
