developer-case-studylisted

# 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. 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 mana