Writing Technical Documentation, Implementation Guides & Building Long-Term Customer Relationships

The build isn't done when the code runs — it's done when someone else can use, maintain, and trust it over time. This tutorial covers the written handoff (technical documentation and implementation guides) and the human handoff that outlasts any single project (long-term customer relationships). Together they're what make you leave the customer capable and still calling you next time.

Table of Contents

• Writing Technical Documentation
• Write for the Reader, Not the Author
• The Document Skeleton
• Writing Implementation Guides
• An Implementation Guide Is a Recipe
• The Setup Section
• Keeping Docs Alive
• Building Long-Term Customer Relationships
• Trust Is Built in Small Moments
• The Relationship Bank Account
• Staying Useful After Handoff
• Handling the Inevitable Miss
• Growing the Account Honestly

Writing Technical Documentation

Technical documentation is the written record of what you built and how it works — for the customer's team to operate it and for anyone (including you, in six months) to understand it. Good docs mean fewer "how do I…" messages; bad docs mean you become the permanent help desk.

Why it is useful: an FDE's goal is a customer who can run without them (Chapter 1). Documentation is the lever that makes that possible. Undocumented work decays the moment you leave.

Write for the Reader, Not the Author

The classic error: documenting what you did, in the order you thought about it. Write for the person opening the doc cold, who knows none of it.

AUTHOR-CENTERED: "So I refactored the loader to use the new client, and
                 then wired the webhook, and oh the config changed too."
READER-CENTERED: "To send data to the report: (1) set these 3 config
                 values, (2) start the loader, (3) confirm the webhook
                 fired. Details below."

Explanation: the first is a diary; the second is a manual. The reader wants steps in the order they'll perform them, not the order you discovered them.

Best Practice: after writing, hand the doc to someone who wasn't in the room and ask them to do the task from it alone. Where they stall, the doc failed — fix there.

The Document Skeleton

Most customer-facing technical docs share a skeleton. Fill it every time; gaps are where confusion lives.

DOC SKELETON — <what this is>
1. WHAT IT DOES      (one paragraph, in their outcome language)
2. PREREQUISITES     (accounts, access, things that must exist first)
3. HOW TO USE IT     (the daily task, step by step)
4. CONFIGURATION     (every setting, with a plain explanation of each)
5. TROUBLESHOOTING  (the 3 most likely failures + the fix)
6. CONTACT / NEXT    (who to ask, what phase two looks like)

Explanation: section 1 sets context before steps (Tutorial 1's "outcome first"). Section 5 prevents the most common support tickets. Section 6 closes the loop so the relationship continues.

Note: keep it short. A 3-page doc people read beats a 30-page doc people fear. Link deeper reference material instead of embedding it.

Writing Implementation Guides

An implementation guide is the stricter cousin of docs: it tells a technical reader exactly how to build or deploy the solution — commands, files, order. Where documentation says "here's what it does," the guide says "here's how to make it exist."

Why it is useful: when the customer's engineer needs to stand up or rebuild the system, a precise guide is the difference between a smooth handoff and a week of "what did you mean by step 3?"

An Implementation Guide Is a Recipe

Treat the guide like a recipe: ingredients listed, quantities exact, steps in order, expected result stated. Vagueness in a recipe produces a different dish.

RECIPE-SHAPE GUIDE
INGREDIENTS:  Python 3.11, package X v2.1, a .env with 3 keys (listed)
STEP 1:       pip install -r requirements.txt
STEP 2:       cp .env.example .env   # fill in the 3 keys (see table)
STEP 3:      python loader.py --init
EXPECTED:     "Connected. 1,240 rows synced." printed; no errors.

Explanation: every step has a command, and the guide states what success looks like ("1,240 rows synced"). Without the expected output, the reader can't tell if step 3 worked — so they ping you.

Best Practice: number every step and make each one either a single command or a single decision. A step that says "now set everything up" is not a step.

The Setup Section

The setup (prerequisites + configuration) section is where guides live or die. Be exhaustive about what must exist first.

Common Mistake: assuming the reader has what you have. You had credentials, a venv, and context. They have a fresh machine and a deadline. The setup section exists to fake your environment for them.

Keeping Docs Alive

Docs rot the moment the code changes. A stale doc is worse than none — it tells a lie with confidence.

• Update in the same breath as the change. Fix the code, fix the line.
• Date or version the doc. "Last updated: v2.1" tells the reader if it's current.
• Mark unknowns. "Step 3 behavior untested on Windows" is honest; silence is a trap.

Note: if the customer maintains the system, hand them doc-ownership explicitly: "you'll keep this updated as you change it." Otherwise it silently dies the week after handoff.

Building Long-Term Customer Relationships

A single delivered project is a transaction; a long-term relationship is a career asset. It means an ongoing, trust-based connection where the customer turns to you first when a new problem appears — not because they're locked in, but because you've earned it. The docs above are the written half of that; this section is the human half.

Why it is useful: relationships compound. The second project with a trusting customer takes a fraction of the discovery cost of the first, because they already believe you'll do right by them. For an FDE, that's leverage no codebase gives you.

Trust Is Built in Small Moments

Trust isn't won in the big demo; it's accrued in dozens of small, reliable moments — answering the "dumb" question fast, shipping the recap you promised, admitting the bug before they found it.

TRUST BUILDERS (cheap, repeated)
- Reply to the small question within a day, even if just "looking."
- Do what you said you'd do, when you said you'd do it.
- Tell them the bad news before they hear it elsewhere.
- Remember their workflow from last time ("your Friday close").

Explanation: none of these is heroic. Together, repeated, they signal "this person is reliable and on my side" — which is the whole relationship. One broken promise outweighs ten pleasant calls, so protect the small commitments hardest.

Best Practice: treat the boring follow-through as the real work. The flashy prototype gets the applause; the reliable reply gets the renewal.

The Relationship Bank Account

Think of trust as a bank account. Every reliable act deposits; every miss or over-promise withdraws. You can survive a withdrawal only if the account is full.

DEPOSITS                          WITHDRAWALS
kept a promise on time            missed a date without warning
surfaced a risk early             hid a problem until it blew up
solved their actual problem       built what they asked, not what they needed
remembered their context          made them re-explain everything

Explanation: the account metaphor explains why a trusted customer forgives a slip (balance covered it) while a new one explodes at the same slip (empty account). Build balance before you need it — you don't know when the withdrawal is coming.

Note: never manufacture deposits by over-promising. A promise you can't keep is a withdrawal in advance, plus interest.

Staying Useful After Handoff

The relationship doesn't end at handoff. The customers who call you next time are the ones you stayed lightly present with.

• A check-in, not a pitch. "How's the report holding up?" two weeks later costs five minutes and signals care, not sales.
• Share something useful. a relevant article, a tip, a new feature that fits their workflow — value with no ask.
• Be reachable, bounded. a known channel and hours; not 24/7, but never a black hole.

Best Practice: the best "account growth" is genuine helpfulness with no immediate ask. The ask comes later, naturally, because you were useful first. The written docs above are the permanent form of that usefulness.

Handling the Inevitable Miss

You will miss a date, ship a bug, or misunderstand a need. The miss isn't what ends the relationship — the handling is.

BAD:   (silence) → they find out from their boss → "why didn't you tell us?"
GOOD:  "The report slips to Thu. Root cause: their API rate-limit we
        didn't know about. Fix in progress; here's what I'm doing, and
        I'll update you tomorrow regardless."

Explanation: the good version owns it fast, explains the cause (not an excuse), and states the next check-in. That converts a withdrawal into a deposit, because most customers forgive a miss handled with honesty and a plan.

Common Mistake: going quiet when things go wrong. Silence reads as evasion, and evasion empties the account faster than the original miss.

Growing the Account Honestly

A long-term relationship naturally surfaces new work — but grow it by solving, not by selling. The line matters.

Best Practice: the next project should be their idea, triggered by a real pain you spotted. If you're manufacturing urgency to extend the engagement, you're extracting, not serving — and the account feels it.

Note: sometimes the honest answer is "you don't need me for that — here's a tool." Saying it builds the relationship, because it proves you're on their side, not your utilization.