Studio practice · 5 min read
Scope custom software around the job it must do.
A useful brief defines users, boundaries, risks and acceptance conditions before it becomes a long feature list.
In this article
Describe a working day before describing screens
A request for 'a dashboard with an approval system' leaves most of the expensive questions unanswered. Who submits work? Who can approve it? What happens when that person is away? Which existing system contains the authoritative record? Begin with a real task and follow it from the first input to the final outcome, including the awkward steps people currently handle through email or spreadsheets.
For example, a small manufacturing team might need to approve design revisions before a job reaches the workshop. The useful outcome is preventing the wrong revision from being produced. A dashboard is only one possible interface. Identify the people involved, the frequency of the task, the cost of mistakes and the documents already in circulation. That gives a software team enough context to challenge an unnecessary feature and protect an essential one.
Define a thin, complete first release
A first release should support a meaningful journey from beginning to end. For the revision example, that could mean submitting a file, assigning an approver, recording a decision and making the approved revision discoverable by the workshop. It might exclude analytics, complex delegation rules and integration with every historical system. Those exclusions should be written down rather than left as assumptions.
Avoid a first phase consisting only of infrastructure followed by a distant phase in which users finally do something. Technical groundwork is often necessary, but connect it to an observable milestone. A small complete workflow exposes misunderstandings about permissions, terminology and exceptions earlier than a large collection of disconnected screens. It also allows the client to judge whether the project is moving toward the actual business outcome before the full budget is committed.
Turn adjectives into acceptance examples
Words such as fast, simple and secure are useful intentions, but poor acceptance criteria on their own. Replace them with examples and constraints. How large is a typical file? How many people are active at once? Which devices must work? What must happen when a user's access is removed? What information should remain in the audit record after a revision is rejected?
For an illustrative acceptance case: a workshop employee can locate the currently approved revision by job number, while a superseded revision is clearly marked and cannot be mistaken for the current one. Another case might require a submission to remain intact after a failed notification attempt. The exact solution can still evolve. The important point is that both parties share a concrete understanding of what must be true when the feature is accepted.
Investigate the unknowns that can change the price
Some uncertainty can be resolved through a conversation. Other uncertainty needs a technical experiment: a third-party API may not expose the required history, a legacy export may contain inconsistent identifiers, or a large model may not fit the target device. List these risks explicitly and investigate the ones that could invalidate the proposed approach before promising a detailed implementation schedule.
The GOV.UK discovery guidance provides a useful general principle: understand users, constraints and the underlying problem before committing to build a service. A commercial engagement can apply that principle at a scale appropriate to the work. A short paid investigation may produce a data sample, integration test, revised scope and delivery options. That is a concrete deliverable even if the conclusion is to buy an existing tool or change the process instead of commissioning custom software.
Budget for the work around the feature
Data migration, access setup, documentation, deployment, backups and training are easy to omit because they are less visible than a screen. They still consume effort, and they determine whether the software can be used safely. Include responsibility for each in the scope. If the client provides content, credentials or sample data, specify when those inputs are needed and what happens if they arrive late.
Discuss operating costs separately from implementation costs. Hosting, commercial licenses, email services and support may continue after delivery. Agree who monitors failures and who can authorize a production change. Estimate with ranges where uncertainty is real, and state the assumptions behind those ranges. A precise number based on unexamined dependencies is less useful than a clear estimate that shows what could move it and how that uncertainty will be reduced.
Make change an ordinary decision
Requirements often improve when people see working software. The answer is a visible decision process, not pretending the original brief can predict everything. Keep a short backlog with priorities, dependencies and acceptance examples. When a new request arrives, discuss its effect on schedule, cost and existing commitments. It may replace a lower-value item, become a later phase or justify an expanded budget.
Finish each review with recorded decisions and the next observable milestone. Keep the scope readable enough that a client can actually use it. For a modest project, a concise brief, a workflow diagram, acceptance examples, assumptions and a clear responsibilities list can be more effective than a large specification nobody maintains. Good scoping creates room for engineering judgment while making obligations visible. Both sides know what is being built, why it matters and how they will recognize a successful delivery.
Sources & further reading
Primary material behind the discussion and useful places to go deeper. The recommendations and worked examples in this article are our synthesis.
Working through a software or game-development problem of your own?
Talk to Winnitude! ↗Explore our tools ↗