Scope one thing, in writing

Six things: the problem in the customer’s words, the slice you will deliver, the constraints it respects, what it explicitly does not include, how anyone will know it worked, and what happens next. Two pages. If it needs ten, the slice is too big.

The exclusion list is the half that earns its keep. “Not integrated with the practice management system”, “not available on mobile”, “English documents only in this phase” — each is a sentence that prevents an argument, and writing it costs nothing while the goodwill is still high.

By this point the design decisions should be traceable. The option you recommend should rest on the constraints you recorded; the effort should rest on a recipe with steps somebody has actually run; the hardware should rest on arithmetic you can print.

This site is built so you can do that: a stack page shows its difficulty with the factors that produced it, its hardware profiles with the assumptions in the estimate, and its cost model with the exclusions named. Quote from those rather than from memory, and say which numbers are assessments rather than facts.

The commercial version of this module is the 3-Day AI Deployment Sprint: observe, design, deliver one scoped implementation or proof of concept. Its scope section exists to prevent exactly one sentence — that everything will be production-ready in three days — and it is a good template even when you are not selling a sprint.

Note what the sprint refuses. If day one shows the right answer is a product the customer can buy, the engagement ends with the decision document. A scope that cannot end in “do not build this” is a sales document, not a scope.