Developer Case Study

Developer Case Study

You are writing someone else's engineering story. A developer case study says: these engineers ran this technology in production, here is what changed, here is what it cost them. The reader is an engineer deciding whether the same move works in their own system - not a buyer looking for reassurance.

That reader discounts an all-upside narrative on sight. Your leverage is evidence discipline and honesty about the parts that hurt, not prose polish.

Scope check

Confirm the artefact before starting. Route elsewhere when:

• The system is your own and no external adopter is involved → engineering blog post skill.
• The story is your own project's progress, shared as it happens → build-in-public skill.
• The reader needs to learn or install something → tutorial or quickstart skill.
• The material is "what shipped in v2.4" or "how to move from v1 to v2" → changelog or migration-guide skill.
• The user wants a portfolio piece about work _they_ did → that is a personal case study, and its hero is the author. Say so; this skill inverts that framing.

See the References section for the exact identifiers.

Interview

Ask the case-study owner these before touching the story, one question at a time, multiple-choice where you can. Stop as soon as you can judge whether the story is publishable.

Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

1. Who is the adopter, and is this in production today or still an evaluation?
2. Who will you interview, and what is their hands-on role? Can you also get their manager or the platform owner?
3. What evidence already exists on your side - support threads, migration issues or PRs, usage telemetry, account notes, their own blog posts or talks?
4. What changed, in numbers, and who inside their team can vouch for those numbers?
5. Who grants permission to name the company, the person, and to use the logo - and how long does each take?
6. Is there a security or legal review on their side, and has anyone engaged it yet?
7. Where does this publish, and does it need a sales one-pager version too?
8. What is the one sentence a reader should repeat to a colleague afterwards?
9. By what date must this be live, and what happens on that date? A date inside the month deletes any enterprise candidate whose legal review alone runs longer, and promotes the adopter who can approve in a message.
10. One-off win - a study for one stalled deal - or a story bank you keep filling? A one-off promotes whichever candidate is closest to approval; a bank promotes the empty row in the coverage table, even when that row is the slowest story to land.
11. What is the effort ceiling, counting the customer's time and goodwill as well as yours? One interview and one review round rules out multi-stakeholder enterprise stories; an account team willing to spend a quarter of relationship capital opens them.

If your harness has persistent memory, store the answers to 5, 6 and 7. Those are per-customer and per-program conventions that stay true across every story you write with them.

Workflow

1. Qualify the story against the gates below, and where several adopters are candidates, rank them with "Which story to chase first" before spending an hour on any of them. Kill or downgrade here - a story that fails the gates cannot be rescued in editing.
2. Reconstruct it from your own evidence first. Read the tickets, issues, PRs and telemetry before the call, so you arrive with specifics to confirm rather than open prompts to fill.
3. Open the approval track in parallel. Read the contract's publicity clause, then ask who grants quotes, metrics and security clearance before drafting - their answer decides which version of the story is writable.
4. Run the source interview. Follow ./references/source-interview-guide.md. Record with consent, keep the transcript.
5. Build the evidence ledger. One row per claim the study will make: the claim, its evidence class, the instrument behind it, who can re-derive it. Do this before drafting.
6. Confirm the spine and the headline number with the owner. Cheap to change now, expensive after 1,200 words.
7. Draft against the spine in ./references/case-study-outline.md, quotes verbatim from the transcript.
8. Write the limitations section from the interview's cost and unsolved-work answers. Never skip it - see below.
9. Run the humanizer pass, then the publication gate. Iterate until every check passes.
10. Send for approval with a marked decision list and a dated deadline, per ./references/approval-and-anonymization.md. Apply their edits, then package the derivative versions.

Invocation examples

• "We just finished migrating Northwind's billing pipeline onto our workflow engine. Write the case study." → run the whole workflow from step 1.
• "Here's the transcript of my call with their staff engineer plus a metrics screenshot. Draft it." → skip to step 5; build the evidence ledger from the transcript, flag every claim the transcript cannot support.
• "Legal came back and killed the company name. What now?" → jump to the anonymization ladder, propose the next rung down, and name what it costs.
• "Is this story even worth writing?" → run the qualification gates only, and answer with a verdict plus the missing gate.
• "We have four customers who said yes, which do we do?" → the ranking in "Which story to chase first", applied to the four by name, with the ones their constraints delete removed rather than ordered last.
• "Turn the approved Northwind study into a one-pager for sales." → derivative versions only; confirm the existing approval covers the new surface first.

Unless the user asks for something else, deliver six parts in this order:

1. Verdict line - publishable, publishable as X, or not yet, with the reason.
2. Evidence ledger - one row per claim: claim, class, instrument, window, who can re-derive it.
3. The draft - the eight-section spine, quotes verbatim, limitations included.
4. Approval package - the decisions to confirm, marked, with a suggested deadline and default.
5. Gate report - the seven checks, each pass/fail, with the fix applied.
6. Derivatives - the one-pager or other requested versions, only after approval.

Produce the verdict and the ledger before any drafting. A ledger built after the prose is a ledger written to justify it.

Story qualification gates

Five gates - this skill's own checklist, not a published standard. A publishable story clears all five:

• Production, not pilot. Real traffic, real consequences. An evaluation is a testimonial at best.
• A measured before-state. No baseline means no honest delta, only vibes.
• A named human who will talk. Nobody to quote means nobody to believe.
• A decision a reader can reuse. Alternatives were considered and one won for a stated reason.
• A plausible path to approval. Someone can actually authorise the company name or a workable anonymised version.

Failing one gate does not always mean no story:

• Missing production: wait.
• Missing baseline: publish a scale/architecture story without a delta claim.
• Missing approval: descend the anonymization ladder.
• Missing a human: it is an engineering pattern post, not a case study. Say that out loud rather than dressing it up.

Which story to chase first