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.

Confirm the artefact before starting. Route elsewhere when:

See the References section for the exact identifiers.

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.

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.

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

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

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

Failing one gate does not always mean no story:

When several adopters could carry a study, the choice is not which one is most impressive - it is which one returns the most published proof per hour spent, counting the customer's own time and goodwill as the scarcest input. Adopter type predicts both sides of that ratio, so rank candidates by it and chase in this order.

The value line assumes the reader is evaluating for a team inside a company. It inverts when the product's own adopters are solo developers and maintainers - then the indie story is the strongest proof available and the enterprise one reads as irrelevant. Re-rank against who actually buys before using the default.

In efficiency order, with what each type costs and buys, and the craft difference each forces:

What this order starves is the named enterprise production reference: the strongest proof available to a reader who has to justify the choice internally, and the most expensive story on the list in both legal review and customer goodwill. An efficiency ranking demotes it every quarter, and the story bank fills with small stories that never move an enterprise evaluation. Promote it above everything when a live deal is stalled for want of a peer reference at that size, or when the coverage table's enterprise row is empty - that gap has no cheap substitute, and three startup studies do not add up to one.

Delete rather than demote. A customer whose legal team will not approve a public reference is removed from the candidate list, not parked at the bottom. Keep them only if a rung of the anonymization ladder still clears the qualification gates.

Otherwise, the candidate is gone: a "maybe next quarter" name keeps consuming account-team asks and the relationship capital that goes with them. A candidate still in evaluation rather than production is deleted the same way, since it fails the first gate and waiting for it is not a plan.

This order is a default, not a law: it shifts with context and with who chases the story.

Every number carries four attributes or it does not ship:

Two well-sourced numbers beat six loose ones. Ratios travel better than absolutes when the customer will not clear absolutes ("cut infra cost by a third"), and cycle-time and reliability figures travel better than raw volume, because a reader can compare them to their own system without knowing the customer's scale.

Don't:

Hold this skill's own numbers to the same rule. ./references/evidence-and-sources.md splits every threshold in this file into sourced or self-set. Quote a self-set baseline only as a working baseline - never to an adopter as an industry standard.

Published studies converge on Challenge / Solution / Results: four independent instances carry the same three beats - two vendor studies and two generic marketing-skill templates (sources in ./references/evidence-and-sources.md). Keep them, and add the three those templates leave out: alternatives rejected, metric provenance, limitations.

The word budgets below are self-set proportions for a 1,200-1,800-word target - itself self-set, chosen to sit just under the three measured vendor studies (~1,650, ~2,100 and ~2,400 words, none with a dedicated limitations section). Scale them to the material.

Sections 4, 5 and 7 are what separate this from a testimonial. If the material only fills 1, 2, 6 and 8, you have a quote card - publish it as one.

Read ./references/case-study-outline.md for the per-section guidance and worked positive/negative examples before drafting. The examples there (Acme, the Grafana figures) are invented illustrations, not measured cases - never cite them as evidence.

A limitation is a cost the reader would inherit, not a plan.

Roadmap: "We plan to consolidate the two languages."
Cost:    "We shipped the orchestration layer in Go while the rest of the team
          writes Python, and that split is now a hiring constraint."

One of the compared studies carries three of the former and none of the latter - do not accept that trade.

The gap is a publisher's choice, not a genre constraint. Across the four compared studies - a small sample, and both vendor ones from the same vendor:

Section lists and sources: ./references/evidence-and-sources.md.

Fill the section from the interview:

State who should not copy this architecture.

Read the contract's publicity clause before asking anyone for anything. Standard self-serve SaaS terms often already license the customer's name and logo and the statement that they are a customer - Vercel's terms carry such a clause, quoted verbatim in ./references/approval-and-anonymization.md.

The clause grants nothing else:

Ask for exactly what it leaves open.

Four permissions remain, often held by four different people:

Ask who holds each at first contact.

Pre-redact what security review predictably strikes:

Send the full draft with the decisions marked, a dated deadline, and a stated default.

When naming is refused, descend the anonymization ladder one rung at a time rather than dropping the story:

Each rung costs credibility, and the last one is no longer a case study.

This ladder is deliberately not ranked by effort or efficiency: the rungs are not alternatives anyone picks between, since every one below the top is cheaper only because someone refused the one above it. Take the highest rung approval allows, and read the descent as loss, not as a trade-off.

Full ladder, redaction classes and a request template: ./references/approval-and-anonymization.md.

Run the prose through your preferred humanizer skill before the gate. Model-flavoured filler reads as vendor copy, which is the register this artefact most needs to avoid.

Preserve exactly as written: every quote, every number, version strings, component names and the architecture description. A humanised quote is a fabricated quote.

Seven checks - a working gate, not a published standard. Hold the study until all seven pass. Report which check failed and what you changed, then re-check.

Then two human reads happen before publishing:

One approved study feeds several artefacts. Ask which are needed before approval, so permission covers them, and build them in reuse-per-hour order - every rung below reuses material the approved study already cleared, so the ranking is about where the reuse lands, not about writing effort:

File the study's atoms - each metric, each quote, the architecture diagram - into a proof library alongside the narrative, with a public/private flag. Assets built later pull from the atoms; nobody re-reads a 1,500-word study to find one number.

Republication in a paid or ad context usually needs its own permission. Re-verify any study older than roughly 18 months before reusing it - a self-set convention, not a measured shelf life; shorten it for adopters who ship fast or churn.

Judge a study on whether it moved evaluations forward, not on traffic. No published metric isolates case studies aimed specifically at developers: general B2B-technology-buyer research puts vendor-produced case studies well behind product demos and free trials for buying-decision impact (see ./references/evidence-and-sources.md), but nothing narrower than that exists. Treat the signals below as things to weigh, never targets to hit:

Do not attribute revenue to a single case study. Overclaiming attribution is the same credibility failure the artefact exists to avoid.