← The Fractional Playbook

The Contracts I Actually Use With Clients (Templates Included)

The two contracts behind all my client work, including what they cover, how they're structured, and how to use them.

The Contracts I Actually Use With Clients (Templates Included)

Note: This piece uses illustrative placeholder figures, not real client numbers. Templates are for reference only. Have a lawyer review before using in your own business.

The templates

If you read about my friend hitting a ceiling at his job and started doing the "how many clients would I need?" math, this is the next step: what you actually send those clients when they say yes.

When I first started doing my own thing, I didn't have a contract. I had a Google Doc, a vague sense of what "the project" meant, and a lot of hope. It worked until it didn't. A scope conversation went sideways, a payment got delayed, and I realized nobody hands you a contract when you go independent. You're expected to just know.

So if you're early in this… still taking on your first few clients, still Googling "how to write an SOW" at midnight, this one's for you. I'm giving away the two contract templates I actually use, stripped of any real client info, so you can see the structure without guessing at it.

Use the first when there's a clear finish line — brand and site. Use the second when the work is iterative and ongoing — UX and product design.

Why two contracts, not one

The instinct early on is to write one contract and reuse it for everything. That works until a client asks "can you also just quickly..." and you realize your agreement has no language for that at all.

The scoped contract is for anything with a defined deliverable and a finish line — a rebrand, a website, a pitch deck. You know what "done" looks like before you start, so the contract can be specific: fixed fee, fixed deliverables, fixed timeline.

The retainer contract is for anything that evolves: ongoing product design, fractional creative direction, ongoing UX support. You don't know in month three what you'll be working on, so the contract has to flex: monthly rate, rolling scope, renewable term.

Mixing these up is where people get burned early. Use a scoped contract for open-ended work, and you're stuck having "that's not in scope" conversations every other week. Use a retainer contract for a one-off project, and you're quietly underselling a defined deliverable.

The details that actually matter

The boilerplate: payment terms, IP transfer, confidentiality, is table stakes. Any template gives you that. The parts that actually do the work are smaller:

  • The feedback SLA. My scoped contracts require client feedback within 24 to 48 hours of each round. Not because I'm precious about speed, but because my timeline depends on their responsiveness. Unwritten, delays quietly become my problem instead of theirs.
  • The milestone payment split. A third at signing, a third at the midpoint, a third at delivery. It protects cash flow and gives the client a natural checkpoint before things get too deep.
  • The explicit scope fence. My brand contracts state plainly what's not included — usually product or UX work — so there's a clean, named reason to open a second conversation instead of quietly absorbing more work into the same fee.
  • The weekly hold. Both contract types require one hour a week from someone with actual decision-making power, not a proxy who "has to check." This single line has saved more timelines than anything else in the document.

None of this is legal cleverness. It's operational honesty — writing down the conditions that actually decide whether a project stays on track, instead of hoping goodwill covers it.

What you're getting

Two fully anonymized templates, built from real engagements:

  • A scoped Statement of Work with a fixed fee, milestone payments, parallel workstreams, and clear scope boundaries.
  • A retainer Design Agreement with a monthly rate, phased engagement, a renewable term, and an optional add-on menu.

Swap in your own numbers, your own scope, your own cadence. The structure is the part that takes years to get right on your own. You don't have to spend those years too.

Why these contracts are worth stealing

These aren't theoretical templates written for a blog post. They come from real design and product work.

They lock scope without killing the relationship. The SOW draws a hard line around what's included — brand and site, say — and what isn't — in-product UX — while still pointing to a separate conversation when you want to go beyond that. It's honest, not defensive.

They protect your time, not just your fee. Both agreements bake in weekly cadence and feedback windows. Not "we'll meet sometimes," but "you owe us one hour a week and 24 to 48 hour feedback on rounds." That's what keeps projects from quietly sliding off the rails.

They separate project work from ongoing support. One document is a one-time full build. The other is a monthly UX retainer with phases. That clean separation is what lets you say "this lives in the retainer, this lives in the project" instead of turning every engagement into a blurry hybrid.

They handle ownership and confidentiality sanely. IP transfers only after full payment. You keep limited portfolio rights for case studies. Confidentiality is framed around real client information instead of heavy legal jargon — protective without being hostile.

If you're starting out, you don't need to reinvent all of that from scratch. Use these as a base, swap in your own services and numbers, then have a lawyer tune the edges for where you live.

How to make it yours

Filling in the placeholders is the easy part. Find and replace [Client Name], [X,XXX], and the rest with your own details. A couple of minutes and you're done.

Where it gets more useful is when you want to adapt the language, not just the numbers. Maybe your engagement only has two milestones instead of three. Maybe your scope fence needs to cover something different. Maybe a clause just reads too stiff for how you talk to clients. That's where I'd paste the template into Claude, ChatGPT, or Perplexity and say something like:

"Here's a contract template. I want to change [the specific thing]. Rewrite the relevant section to reflect that, and keep everything else the same."

That's a real editing job, not a fill-in-the-blank exercise — and it's the part AI is actually good at.

Either way: AI can help you draft, but it won't catch jurisdiction-specific legal issues. Have a lawyer glance over the termination and liability clauses before you send this to a real client.

One more thing: I'm building something new called Juggle, made for people juggling exactly this kind of independent, client-based work. If that's you, the waitlist is open at joinjuggle.com.

Thanks for reading,
Gev