My 12-step onboarding doc for every freelance project

Every freelance dispute I've heard about traces back to something that should have been agreed in week one and wasn't. This is the document I fill in with every new client during the discovery week. Twelve items, about 30 minutes to walk through, and the number of post-kickoff "wait, I thought…" conversations dropped to roughly zero.

The shape of the document

It lives as a single shared Notion page (or Google Doc — Notion is just my preference). Both sides edit it during the kickoff call. By the end of the call, it's signed by both parties — informally, just initials on the page — and then it becomes the source of truth that the contract references.

The twelve items, in the order I walk through them:

1. The problem in one sentence

Not "build a dashboard." A sentence that names the specific pain. "The finance team spends every Monday morning building the P&L report by hand and it takes four hours." If we can't write the sentence in 30 seconds, the scope isn't ready and we shouldn't be agreeing on anything else.

2. What "done" looks like

The single most-skipped item, and the source of half of all scope disputes. I write down 3–5 bullet points that describe the state of the world when the project is over. "Finance team uses the dashboard at month-end close. Manual P&L spreadsheet is retired. New analyst can read the dashboard with one walkthrough." If we hit those, we're done. If we haven't, we're not.

3. The 80% feature list

What the dashboard does on day one. Not the dream list — the minimum that makes #2 true. I push back hard on "could it also…" additions at this stage. Every extra feature here pushes the launch date later. The remaining 20% goes into a Phase 2 list that we both look at after launch.

4. The data sources

Every piece of data the dashboard reads, with: where it lives now, who owns it, format (CSV, API, SQL, scraped), refresh cadence, and whether I'll have access during the build or only at integration time. The #1 cause of timeline slip on dashboard projects is "we'll get you the data next week" turning into six weeks.

5. The deployment target

Where this runs. Their VPS? My VPS, billed back? Vercel? AWS? On-prem? Each of these has a different setup cost and a different ongoing cost; both belong in the contract. I've had clients assume "deployment is included" meant "and you'll run the servers forever for free." Write it down.

6. Who owns what at the end

Code: the client owns it under standard work-for-hire. Designs (if any): same. The repo: transferred at handover. Domain names: theirs. Third-party SaaS accounts (Sentry, Postmark, etc.): created under their billing from day one, never mine. Database snapshots: theirs at handover. Documenting this in week one prevents the awkward end-of-project conversation about who owns the AWS account.

7. Communication cadence

One weekly call (30 minutes max), one written Friday status. Slack/Discord/email for async — pick one. Response SLA: I commit to under 24 hours during business days, the client commits to under 48 hours on questions that block me. Without the client SLA, "I'm blocked waiting on Sarah" becomes a recurring weekly status line.

8. Payment structure

Fixed-price: 30% on kickoff, 40% at the agreed mid-point milestone, 30% on handover. Hourly: invoiced fortnightly, NET-7 terms. Late payment terms: 1.5% per month after 14 days late. Currency: USD by default for international, INR for Indian clients. None of this is up for negotiation after kickoff.

9. What I'm NOT doing

This list is as important as the feature list. "Not building a mobile app. Not handling the email-send infrastructure beyond plugging in a service the client provides. Not integrating with Salesforce. Not writing marketing copy for the landing page." Anything plausibly adjacent that I'm not doing goes here.

10. Change-request process

How new scope gets added during the project. Mine: write the change request in our shared doc, both sides agree on the price/timeline impact in writing before I touch code. Without this, scope creeps a feature at a time and the launch slips into something nobody planned for.

11. Handover deliverables

The list I commit to producing at the end. Typically: source code (in a repo I transfer), README that gets a new developer running in under 15 minutes, deployment runbook, database schema doc, two-week post-launch support window for questions. If the client wants more (recorded walkthroughs, end-user training, a maintenance retainer), that's a separate line item.

12. The "things that would change my mind" list

Honest signals from the discovery conversation that, if they turn out to be true, would change my pricing or my willingness to take the project. "You mentioned the existing system was 'mostly stable' — if it turns out to be three years of unfixed bugs that need ground-up rewriting before I can add features, that's a separate project." Surfacing these in week one — when both sides can still walk away cleanly — is the gentlest possible course-correction.

What this catches before it becomes a problem

The actual disputes I've avoided since adopting this doc, in rough frequency order:

• "I thought that feature was included" — caught by items 3 and 9
• "When do I pay the next instalment?" — caught by item 8
• "Who's hosting this after launch?" — caught by item 5
• "Can you tweak just one more thing before invoicing?" — caught by item 10
• "We can't find the production credentials" — caught by item 6

One thing I keep meaning to add

A 13th item: end-of-project retrospective. Thirty minutes, two weeks after handover. "What worked, what didn't, would you work with me again?" The handful of times I've done this it's been valuable — it's how I learned that finance teams care about audit logs more than they care about chart polish (a lesson I've written about separately). But I forget more often than I remember. Working on it.

The 12-step doc is the front end of how I work with clients. The services and pricing context is on the services page, and the background is on the about page.