The most valuable document in a software project is also the least exciting. It is a plain-language description of what “done” means, written down and agreed to before anyone opens a code editor. We write it with you, and we do not start building until we both recognize the finish line in it.
Carpenters have a saying: measure twice, cut once. Software has the same physics and half the discipline. The difference between a project that lands on time and one that drifts for a year is rarely the code. It is whether someone did the boring work of defining the finish line before the cutting started.
Why “done” is so easy to skip
Writing down done forces hard conversations early. It surfaces the features that sound nice but do not earn their place. It makes you choose between the thing you want and the thing you need. Those conversations are uncomfortable, so most projects skip them and pay for it later, when changing course is expensive instead of free.
We would rather have the hard conversation over a document than over a half-built product. A paragraph is cheap to rewrite. A feature is not.
What a real definition of done contains
A definition of done is not a wish list. It is a specific, testable description of the finished system. For the work we do, that usually includes:
- The exact problems the software solves, in the client’s own words.
- Who uses it, and what each type of user can do.
- The screens and workflows that must exist for the job to be finished.
- The rules the system enforces, including the unglamorous ones about permissions, validation, and errors.
- What is explicitly out of scope for this engagement.
That last line does more work than all the others. A good scope is defined as much by what it excludes as by what it includes. “Out of scope” is not a rejection. It is a promise that this build will actually finish, and a marker for where the next one can start.
How it protects your money
A written definition of done is what keeps a fixed price fixed and a timeline honest. It is the shared reference we both point to when a new idea shows up in week six, because new ideas always show up in week six.
When they do, the document lets us answer well. Not “no,” and not an automatic “yes” that quietly blows the budget. Instead: here is the finish line we agreed to; does this belong inside it, or is it the first item on the next scope. That is a decision you make with full information, rather than a surprise you discover on the invoice.
This is also why we quote fixed engagements instead of billing by the hour. Hourly billing rewards a shop for taking longer. A fixed scope points us the same direction you already face: the faster and cleaner we reach the agreed finish line, the better it is for everyone. The document is what makes that alignment possible.
The document is yours either way
We put this thinking into a paid planning phase precisely because it has value on its own, separate from any build. At the end of it you hold a functional design, a visual design, and a real proposal with a timeline and a number. Those deliverables are yours to keep whether you build with us, build elsewhere, or decide not to build at all.
That is not a loss leader. It is the honest shape of the work. Planning is where the expensive mistakes get caught, while they are still just words on a page. A grant reviewer, a board, or a bank can read a clear plan and understand exactly what they are funding. So can you.
Measured twice, built once
Software feels weightless, so it is tempting to treat planning as optional and start typing. The teams that regret it are the ones that learned, expensively, that a wrong assumption caught in a document costs a sentence, and the same assumption caught in production costs a rebuild.
Write down what done means. Agree to it before the cutting starts. Then build toward it, in the open. That is the whole method, and it is most of the reason our projects finish.
Written by
Miles Bassett
Founder and principal craftsman at Prairie Code. He writes and speaks on deliberate AI adoption for small businesses and institutions.