The freelancer calls a contact in a panic on a Wednesday. “I’m drowning, can you take this brief?” The contact says yes. The brief is four sentences. The work comes back Friday and it’s not quite right. The freelancer spends Saturday fixing it, delivers to the client late, and adds a note in their mental list: “don’t do that again.” Then they do it again two months later.
This is not a people problem. It’s a systems problem. The contact isn’t bad at their job, they were handed a four-sentence brief and asked to produce something the client would approve. The system failed, not the subcontractor.
The system that makes subcontracting reliable isn’t complicated. It requires three things: a complete brief before work starts, milestone-based delivery, and a QA checklist before anything goes to a client. Here’s how to build all three.
The 7-field subcontractor brief
Every subcontractor brief needs seven fields. Not four sentences. Seven fields, each one answered in writing before the subcontractor starts.
Field 1: Client background One paragraph. Who is this client, what do they do, who do they serve? The subcontractor will make dozens of judgment calls during the project. Every one of those calls will be better if they understand the client’s business and positioning.
Example: “Meridian Legal is a three-attorney immigration law firm based in Austin. Their clients are primarily small business owners navigating employment-based visa processes. They have a formal but accessible brand voice, they want to sound expert, not intimidating.”
Field 2: Project goal What does this deliverable need to accomplish? Not just what it is, but why it exists. “A homepage redesign” is not a goal. “A homepage redesign that converts visiting small business owners into consultation requests, the current page has a 0.8% conversion rate” is a goal.
Field 3: Deliverable spec Exact format. Exact length. Exact technical requirements. If it’s a written piece: word count range, heading structure, whether links are needed, what file format. If it’s a design: dimensions, file formats, color space, what assets are provided. No assumptions. Write it out.
Field 4: Audience Who is the end reader, viewer, or user? What do they care about? What are they afraid of? What language do they use? A subcontractor who understands the audience makes better calls than one who doesn’t.
Field 5: Tone and style Describe it in concrete terms, not adjectives. “Professional but approachable” tells the subcontractor nothing. “Like the Mailchimp blog, casual in sentence structure, serious in substance, no industry jargon” tells them something actionable. Provide an example if you have one.
Field 6: Constraints What to avoid. Off-limits topics. Brand rules. Competitor names that shouldn’t be mentioned. Technical requirements that can’t be changed. This field prevents the most common revision cycles, the ones where the subcontractor did something reasonable that you needed them not to do.
Field 7: Timeline Three dates: first draft due, your review window (be specific: “I’ll review within 24 hours”), final due. If you have a client deadline, work backward from it and add a 20% buffer for revisions.
A brief with all seven fields answered takes 20–30 minutes to write. It eliminates 80% of the revision cycles that would otherwise happen. That’s the ROI: 25 minutes of writing saves 4–6 hours of correction and re-delivery.
Milestone-based delivery: 30%, 60%, 100%
Never ask a subcontractor to deliver only at completion. By the time they send the final file and it’s wrong, you’ve both wasted all the time it took to build the wrong thing.
The three-milestone structure:
30% milestone: Outline, wireframe, rough draft, or structure. This is directional, is the subcontractor heading the right way? Review it within 24 hours and confirm or redirect. The revision cost at 30% is a fraction of the revision cost at 100%.
60% milestone: First full draft or prototype. This is where the real feedback happens. It should look like a real thing, not a skeleton. Your feedback here is substantive, does this meet the brief? Does it achieve the goal? What specifically needs to change?
100% milestone: Final delivery. At this point, if the 30% and 60% checkpoints went well, the only revisions needed are polish: small language edits, a layout tweak, a formatting fix. Major structural changes at 100% mean one of the earlier checkpoints failed, not the subcontractor.
The milestone structure does one more thing: it builds trust in both directions. You’re not surprising the subcontractor with major feedback at the end. They’re not delivering something that’s been wrong for days without knowing it. The relationship gets easier with each project because the process is predictable.
The QA checklist before client delivery
Before any subcontracted work goes to a client, it runs through this checklist. Build it once and use it every time.
On-brief check:
- Does the deliverable match the format spec from the brief? (length, format, dimensions)
- Does it achieve the stated project goal?
- Is the audience and tone correct? Would the target reader/user recognize this as being for them?
- Are all constraints from the brief respected?
Quality check:
- No typos, grammatical errors, or formatting inconsistencies (read it as if you’re the client)
- All links, references, or assets function correctly
- File is in the correct format for client delivery (not a working file format)
- Version is clearly labeled (Final, not “draft3_v2_REVISED”)
Scope check:
- Is everything that was promised in the proposal present?
- Is anything present that wasn’t in the scope (that might create an expectation issue)?
Delivery check:
- Client-facing file name (not “Subcontractor_FirstName_draft” but “ClientName_Deliverable_Date”)
- Any context or explanation the client needs is ready to send alongside the deliverable
This checklist takes 10–15 minutes to run. It catches the things that would otherwise generate a client email within 24 hours of delivery, which costs far more than 15 minutes to handle.
The QA checklist isn’t a sign that you don’t trust your subcontractor. It’s a system that protects them from being blamed for things you should have caught. Run it every time, regardless of how confident you are in the work. The one time you skip it will be the one time something gets through.
The conversation when the work isn’t ready
At some point, a subcontractor will send work that isn’t ready. This conversation, handled well, doesn’t damage the relationship. Handled badly, vaguely, or with implied frustration, it usually creates defensiveness and worse subsequent work.
The script that works:
“I reviewed the [deliverable] and there are three things I need changed before I can send this to the client:
- [Specific issue], needs to be [specific fix]
- [Specific issue], needs to be [specific fix]
- [Specific issue], needs to be [specific fix]
Can you send the revised version by [date/time]? Let me know if any of these points need clarification.”
That’s it. Numbered, specific, actionable. No “this isn’t quite what I was looking for.” No “I think we need to rethink this.” Specific issues, specific fixes, specific timeline.
If the same issue recurs on a second project, address it directly: “On the last two projects, [specific pattern] has come up in revisions. Before we go further, I want to make sure the brief is clear on this, [restate the relevant field from the brief]. Does this make sense?”
If it recurs a third time, you have a sourcing problem, not a communication problem. Find a different subcontractor.
Building a subcontractor bench
Reactive subcontracting, calling someone when you’re overwhelmed, hoping they’re available, is the worst version of the model. The better version: a bench of 3–4 vetted subcontractors in your primary discipline who know your brief format, have delivered for you before, and have a realistic sense of your quality standard.
Building the bench:
- Complete one paid test project with each person before committing to ongoing work
- Use the brief template on the test project, this is also a test of whether they follow a brief
- Debrief after: what worked, what didn’t, what would you change
- Keep a simple log: who they are, what they’re best at, their rate, their availability signal (full-time freelancer vs. someone with a day job who freelances on the side)
A bench of three reliable subcontractors means you’re never in the Wednesday panic call situation. You know who to contact, they know your process, and the brief template does the work of briefing them quickly even when you’re stretched.
For more on the transition from managing subcontractors to building a team, How Freelancers Transition to Agency covers the full extraction sequence. When to Hire Your First Employee as a Freelancer has the financial thresholds for moving from subcontractors to employees.
Ready to send stronger proposals?
Build, send, and track proposals in one place so follow-up is easier.
Start your free trial →
