Outsourcing software development: write a brief an agency can deliver

SECTION 01

Give the agency a working problem to solve

Start with one paragraph naming the user, the task, and what is currently difficult. Add anonymized examples of the spreadsheets, forms, messages, or reports used today. Explain which system holds the authoritative record when two tools disagree.

Then describe an ordinary case and an awkward one. For an approval tool, that could mean a request accepted on the first attempt and another returned for correction after its manager changes. These examples reveal permissions and state changes that a static design will miss.

SECTION 02

Illustrative example: an equipment request application

Imagine a company requesting laptops through email. Its first release could let an employee submit a request, a manager approve it, and an operations coordinator record fulfillment. Finance still purchases equipment in the existing accounting system. This is a planning example, not a reported Catapult client engagement.

The brief should specify that managers see their team's requests, operations sees approved requests, and employees see only their own. A request returned for correction must preserve its history. Receiving an email notification must not be the only way a coordinator discovers work waiting in the application.

That boundary leaves purchasing, inventory forecasting, and payroll outside the initial project. It also produces a meaningful demonstration: create a request, return it, resubmit it, approve it, and finish it using separate accounts.

SECTION 03

Separate development responsibilities from client decisions

The agency can design and build the agreed behavior, but your business must decide approval rules, access policies, and which historical data is correct. Put both sides in the delivery plan so unanswered questions do not quietly become developer assumptions.

For a remote agency, specify review hours, written decision records, escalation contacts, and expected response windows. U.S. time-zone overlap can matter for coordination; it is not evidence that a supplier is U.S.-based. Ask about the actual team and working arrangement.

SECTION 04

Use review evidence to control scope and risk

Agree small demonstrations during delivery instead of discovering the application only at the end. Each demonstration should show a user completing a task and handling a failure. Keep a decision log separating defects from newly requested behavior.

For security requirements, OWASP ASVS provides a vocabulary for specifying verification work. NIST's Secure Software Development Framework can also inform questions about development practices. Referencing either resource is not a certification: agree which checks are included and what evidence you will receive.

Ask for a change proposal when an addition affects data, integrations, or acceptance. It should explain what changes, what is deferred, and the effect on price and schedule. This makes affordable outsourcing a matter of controlled scope rather than an unexplained low headline quote.

SECTION 05

Make the application maintainable after launch

List the source repository, deployment accounts, database, third-party subscriptions, documentation, and backup arrangements in the handover inventory. Agree access and ownership in writing, including any licensed components. Do not assume that receiving a login gives your business control of the underlying application.

Before accepting handover, have the responsible person run a deployment or recovery exercise with the agency's instructions. Confirm who handles incidents, updates, and future changes. Development delivery and ongoing support are related but separate scopes.

SECTION 06

Frequently asked questions