Contractor Brief Template

A Brief Is a Boundary

A contractor cannot recover context that exists only in the founder’s head. When the assignment arrives as a handful of chat messages—“clean up the onboarding flow,” “make the dashboard production-ready,” “improve the landing page”—the contractor must guess which outcome matters, which product decisions are settled, and which risks are acceptable. The founder then discovers the missing decisions during review, after time and money have already been spent.

Use this artifact after the work has a finish line and the founder can recognize an acceptable result. The brief is not a substitute for conversation or a contract. It is the shared operating record between them: the reason for the work, the boundary around it, the evidence that will close it, and the condition under which either side should stop.

If the desired outcome is still exploratory, say so and buy a bounded discovery engagement. Do not describe uncertain product strategy as an implementation task and make the contractor absorb the uncertainty without authority.

Write the Brief in the Order the Work Will Be Judged

Open one document and complete it before granting production access or asking for a delivery estimate. Delete prompts that do not apply; do not leave them as silent blanks.

CONTRACTOR BRIEF

ENGAGEMENT
Working title:
Contractor:
Founder owner:
Brief version and date:
Proposed start:
Target finish or decision date:

1. OUTCOME AND CONTEXT
Customer or business outcome this work should improve:
Observed problem and evidence:
Why this work is timely now:
Current behavior or starting state:
What a successful result makes possible:

2. ASSIGNMENT BOUNDARY
In scope:
Explicitly out of scope:
Required inputs the founder will provide:
Constraints that must remain true:
Known unknowns:
Assumptions the contractor should verify before proceeding:

3. DECISIONS AND ESCALATION
Decisions the contractor may make:
Decisions the founder retains:
Conditions that require escalation:
Who decides and expected response time:
What should pause while a decision is pending:

4. DELIVERABLES AND ACCEPTANCE
Deliverable or changed behavior:
Acceptance checks and evidence:
Representative cases that must work:
Failure or edge cases that must be handled:
Quality, reliability, performance, accessibility, or security limits:
Who accepts the work:

5. ACCESS AND CUSTOMER TRUST
Systems, repositories, accounts, and data required:
Named account and permission level for each:
Production actions allowed without approval:
Actions that require founder approval:
How secrets and customer data may be transferred and stored:
Logging, backup, or rollback required before consequential changes:
When access and local copies will be removed:

6. WORKING RHYTHM
Primary communication channel:
Progress evidence expected:
Review or demonstration cadence:
Maximum time to spend while blocked before escalating:
How changes to scope, cost, or schedule are proposed and approved:

7. HANDOFF
Source, designs, configuration, and files to return:
Setup, operation, test, deployment, and rollback notes required:
Open risks, deferred work, and unresolved decisions to record:
Knowledge-transfer session or walkthrough:
Final access-removal and ownership check:

8. COMMERCIAL AND ADMINISTRATIVE TERMS
Pricing basis, amount, currency, and payment milestones:
Approved expenses or tools:
Confidentiality, ownership, and permitted reuse terms:
Applicable contract, classification, tax, or data obligations:

9. EXPAND, STOP, OR CLOSE
Evidence that justifies expanding the engagement:
Condition that narrows, pauses, or ends it:
What is payable and returnable if it ends early:
Final acceptance date:
Post-engagement review date, if needed:

The commercial section records the operating facts the work depends on; it does not resolve legal obligations. Contractor classification, intellectual property, confidentiality, tax, and data duties vary by jurisdiction and by the real relationship. Use suitable terms and local professional advice rather than relying on the label contractor.

Buy an Outcome, Then Make It Inspectable

“Implement CSV import” names output. It does not explain why the work exists or how the founder will judge it. A useful outcome connects the assignment to a visible product or business consequence:

Let a founder prepare a standard property-management account from its vendor file without editing production records by hand, while exposing every row that needs customer or founder judgment.

That sentence constrains the solution. A parser that accepts one clean fixture but hides rejected rows has not achieved the outcome. Neither has an elaborate import platform that delays the three formats customers use today.

Acceptance criteria should make review possible without prescribing every implementation choice. For this assignment, they might include:

• show a preview before any record is written;
• preserve the uploaded source file and associate it with the import attempt;
• recognize the three documented input formats and report unsupported columns;
• reject ambiguous vendor matches instead of merging them silently;
• allow the founder to correct or exclude a row before confirmation;
• write an audit record for the confirmed import;
• leave existing records unchanged when validation or confirmation fails;
• demonstrate the normal path, an ambiguous match, and a failed import using representative fixtures.

Each item describes behavior or evidence the founder can inspect. “Follow best practices” and “make it robust” cannot settle a review because neither party knows which consequence those phrases are meant to protect.

Separate Execution From Product Judgment

The contractor needs room to work, but autonomy is not permission to settle the founder’s unresolved product decisions. Name both sides of the boundary.

For the import assignment, the contractor may choose internal module names, test structure, and parsing techniques that fit the existing codebase. The founder retains decisions about whether two vendor records represent the same business, which customer formats become product promises, and whether the import may overwrite existing data. A newly discovered fourth format triggers an estimate and a scope decision; it does not quietly enter the engagement.

An escalation rule is complete only when it says what happens next. “Ask if unsure” still permits one person to continue while the other assumes the work has stopped. Prefer a rule such as:

If a decision can change customer data, permissions, billing, or a documented
product promise, stop that path, record the smallest reproducible example in
the brief, and tag the founder. The founder responds within one working day.
Unrelated work within the accepted scope may continue.

The same precision protects review. Decide whether the founder will inspect a design, a thin vertical slice, a staging demonstration, or the completed work. For risky or difficult-to-reverse changes, waiting for final delivery turns review into rescue.

Grant Access for the Assignment, Not for Convenience

List every required system before access is issued. Use a named account and the least permission that permits the work. Prefer test data, staging paths, temporary credentials, and approval-gated production changes where they can represent the real task honestly.

The brief should say how secrets and customer material travel, where working copies may exist, and when they are deleted. It should also identify actions that need a backup, export, dry run, or rollback plan. “Repository access” is too vague when the same engagement may touch source code, deployment secrets, production logs, customer uploads, and billing configuration.

If the assignment cannot be performed with a defensible access boundary, redesign the assignment or improve the product’s administrative controls first. A deadline does not make unrestricted access safe.

Treat Review as Part of the Work

A solo founder often underprices their own management time. Reserve time to answer decisions, review intermediate evidence, test the acceptance path, and correct the shared brief. If the founder cannot provide that time, reduce the scope or move the start date.

When a correction repeats, repair the system around the engagement. Clarify the brief if the rule was hidden, change the product or tool if it can prevent the error, or return the case to the founder if it still contains product judgment. Repeated private correction teaches dependence rather than creating leverage.

Scope changes belong in the brief with their effect on cost, timing, and acceptance. A useful change note is small:

CHANGE NOTE
New evidence or request:
Why the current scope does not cover it:
Proposed change:
Cost and schedule effect:
Acceptance effect:
Decision: accept / defer / replace existing scope
Approved by and date:

Close the Engagement Before Expanding It

Delivery is not complete when a pull request merges or a design file arrives. The founder should possess the source and configuration, understand how to operate and reverse the result, know what remains uncertain, and be able to remove the contractor’s access without disabling the product.

Read the handoff against the acceptance evidence, not against the volume of activity. Record deferred risks and rejected paths while their reasons are still available. Then choose explicitly: close the engagement, extend the same bounded work, write a new brief, or redesign the process because the work did not travel as expected.

Expand only when the result holds, review is becoming lighter, and the next work parcel is equally clear. A successful contractor relationship does not make an ambiguous assignment safe. Each new boundary must be written.

The next collaborator may need more than the result of one engagement. If the work enters the codebase or operating system, convert the relevant setup, architecture, deployment, and recovery knowledge into a codebase handoff that another person can use without reconstructing the founder’s memory.