In our experience, the best projects are the ones that were scoped well from the start.
That sounds like a platitude until you see what the alternative costs. A project that starts from a conversation instead of a document ends up being scoped during the build, one surprise at a time, at the most expensive point to be making decisions.
The fix is not a long specification. Long specifications get skimmed, contradict themselves by page forty, and give everyone the feeling that the thinking is done when it isn't. The fix is one page.
Why One Page
A single page forces the decisions a long document lets you avoid.
There is no room for "and eventually it could also." There is no appendix to hide the uncomfortable parts in. If something matters, it has to earn a line. If it doesn't fit, it probably belongs in a later piece of work.
One page is also something your executive director, your board treasurer and your developer will all actually read. That matters more than completeness. A document that three people understand beats a document that one person wrote.
You do not need to be technical to write it. Most of it is about your work, not about software. The technical half gets filled in with whoever builds it.
What Goes on the Page
Nine short sections. Most take a sentence or two.
1. The Problem, in One Sentence
What is wrong today, in plain words. "Staff re-key every new registration from the event platform into the AMS, and it takes most of a day after each event."
If you need a paragraph, you probably have two problems. Pick one.
2. Who This Is For
The specific people who will use it on day one. Not "the organization." Not "members, eventually." The two people in membership services who do the re-keying.
3. How It Works Today
The current process, step by step, as it actually happens. Include the workarounds and the step that exists because of something that went wrong years ago.
This is the section people skip, and it is the most valuable one. The developer cannot design around steps they don't know exist. Ask the person who does the work to write it, not their manager.
4. What "Done" Looks Like
Describe the finished state from the user's point of view. "A new registration appears in the AMS within an hour, matched to the existing member record, with no one touching it."
If you can't describe done, you can't tell when you've arrived, and neither can the person you're paying.
5. What It Touches
Every system the work reads from or writes to, and who controls each one. Your AMS, your email platform, a spreadsheet on someone's desktop. Note which ones have a vendor you'd need to call for access.
6. The Exceptions
What happens when the input is wrong, incomplete or unusual. A registration with no email address. A member who appears twice. A payment that failed.
You don't need to solve these here. You need to list them. Most estimates go wrong in the exceptions, not the main path.
7. What It Won't Do
The out-of-scope list. This is the most protective section on the page.
Write down the reasonable things you are deliberately not doing yet: the reporting dashboard, the second event platform, the member-facing view. When someone says "while you're in there," this is where you point.
8. How You'll Know It Worked
One or two numbers you can measure before and after. Hours per week. Errors per month. Days from sign-up to access.
Measure the before now, while it's still happening. Once the new system is running, nobody remembers how long the old way really took. We covered this in more detail in What to Measure Before and After an Automation.
9. Constraints
The date that actually matters and why. The budget range. Anything that must not change, like the member login or the payment processor.
What the Page Is Not
It is not a design. It says what and why, not how. Leave the how to the people building it, and judge their answer against the page.
It is not a contract. It is the thing the estimate is based on. When the estimate comes back, you should be able to hold the two side by side and see that every line of scope is accounted for, and nothing extra has crept in.
It is not permanent. It will change after the first conversation with the developer, and it should. What it gives you is a record of what changed and why.
The Overbuilt Version One
The one-page scope protects against two failures, and people usually only think about one of them.
The obvious failure is under-building: something important was never discussed and turns up late. The quieter failure is over-building. A developer on one client's team described a previous project this way: the person who asked for it wanted a Hyundai, and they built him a Mercedes. A beautiful system, more expensive than necessary, solving problems nobody had.
Over-building happens when the scope is vague, because a vague scope lets the builder fill the gaps with what they think would be good. Section 7, the out-of-scope list, is what stops it.
A Worked Example
Here is roughly what a finished page looks like for a small integration.
- Problem: Event registrations are re-keyed by hand into the AMS, about six hours after each event.
- For: Two membership coordinators.
- Today: Export the registrant CSV, clean it in Excel, search the AMS for each person, update or create the record, tag the event.
- Done: Registrations sync to the AMS automatically, matched to existing members, with unmatched records listed for review.
- Touches: Event platform (read), AMS (write). AMS vendor must enable API access.
- Exceptions: No email address; duplicate members; company registrations for multiple people.
- Won't do: Historical registrations, reporting, the second event platform.
- Measure: Hours spent per event on data entry, before and after.
- Constraints: Live before the spring conference. Member login unchanged.
That's the whole thing. A developer can estimate from it. A board can approve from it. Staff can check the result against it.
How to Use It
Write the first draft yourself, before you talk to any developer. Then bring it to the conversation and expect it to get marked up.
A good developer will ask questions the page doesn't answer, suggest cutting something, and add an exception you hadn't thought of. That is the page doing its job. If a developer reads it and has no questions at all, pay attention to that too.
For guidance on keeping the scope itself small, see How to Scope a First Custom Build Without Over-Building.
A Simple Rule of Thumb
If you can't fit the project on one page, it is more than one project.
Split it, write a page for the first piece, and build that.
Final Thoughts
Writing it down is the cheapest part of any custom build and the part most often skipped. An hour on one page saves weeks of decisions made in the middle of a build, when every change touches work that's already done.
If you've drafted a scope and want a second set of eyes on it before asking for estimates, we're happy to go through it with you. Book a short consult.