❯ Write the case study before you write the pitch deck

2026-09-24 ·5 min read

by Priya Anand — the product desk, Side Quest Studios September 25, 2026

Your best marketing asset is a log file with a customer's name on it. Not a testimonial. Not a logo wall. A case study written the way an operator writes an incident report: what was on fire, what you typed, what happened next. Founders avoid this because they think they need permission, permission costs a phone call, and a phone call might end in "no." So they write another thought-leadership post instead. Stop. You already have the material. It's sitting in your support inbox and your git history.

I've kept fleets alive at 3am and I've written hundreds of these. The ones that move money share one property: a reader can reconstruct the fix from your writeup without emailing you. That's the whole standard.

The graveyard is full of companies with great decks

Look at what's actually dying right now. There's now a running list of AI projects and startups that didn't make it — big names, real funding, shipped nothing anyone could verify the AI graveyard. Every one of those had a narrative. Almost none had a case study with a timestamp in it.

Meanwhile Meta is shipping MCP plumbing so coding agents can do the tedious WhatsApp Business setup — templates, testing, troubleshooting — because that work is boring, verifiable, and someone will pay to not do it Meta's WhatsApp Business MCP. Notice the pattern. The durable stuff is boring, specific, and checkable. Your case studies should look like that plumbing. Not like the pitch that raised the round.

The four-line skeleton

Every case study I write has four sections. No more.

Situation. Two sentences. What was true before you showed up. Numbers or nothing: "38 Postgres connections, 4 vCPU box, p99 latency 2.1s under load."

Problem. One sentence naming the actual failure mode. Not "scaling challenges." Something like: "Every write triggered a full table scan because the index had been dropped in a migration two quarters back."

Intervention. This is the meat. The literal commands, the config diff, the commit hash. Not "we implemented a caching layer." Show the file.

Result. Measured, with the measurement method. "p99 dropped from 2.1s to 340ms over a 24-hour window, measured by pg_stat_statements." If you don't have a before/after number, say so and explain what you'd measure next time. Honesty about missing data reads as competence, not weakness.

That's it. Four sections. If a section runs past 300 words you're explaining, not reporting.

Show the actual command

Here's the difference between a case study that converts and one that doesn't. Bad: "We optimized the database." Good:

terminal bash (80x24)

$ EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 4821;
Seq Scan on orders  (cost=0.00..184320.00 rows=1 width=312)
                   (actual time=1893.221..1893.221 rows=1 loops=1)

Then the fix:

CREATE INDEX CONCURRENTLY idx_orders_customer_id ON orders (customer_id);

Then the after:

Index Scan using idx_orders_customer_id on orders
  (cost=0.43..8.45 rows=1 width=312) (actual time=0.041..0.043 rows=1 loops=1)

Three blocks of text. Nobody can fake that. Any founder reading it knows within five seconds whether you've actually done the work. That's the point — it's a filter, and it filters in your favor.

Same thing in Python. If your intervention was a config change, show the diff:

# before
CONN = psycopg2.connect(dsn, connect_timeout=30)

# after
POOL = psycopg2.pool.ThreadedConnectionPool(
    minconn=4, maxconn=20,
    dsn=dsn, connect_timeout=5,
)

The connect_timeout=5 is the whole story. Under a network blip, 30 seconds times 200 concurrent requests means your worker pool is dead before you even see the error. Five seconds and a pool means the blip is a blip. That's the kind of sentence that earns a phone call.

Numbers without lying

You will be tempted to round up. Don't. The founder who's been burned by hype can smell a 10x claim from the parking lot.

Rules I actually follow:

One metric per claim, with a window. "p99 latency dropped 84% over a 24-hour window" beats "10x faster." Always include the window; it signals you know what a measurement is.
Name the measurement tool. pg_stat_statements, py-spy, perf, wrk, hey, sysstat, whatever you used. If you used a stopwatch, say stopwatch.
Report the cost too. "Added 2GB of RAM, kept the same instance size, saved $340/month by dropping a paid APM tool." Costs are the part nobody publishes and everybody wants.
If you don't know, write "unknown." I've written "we never measured the counterfactual, so I can't tell you what would have happened without the change" in a published case study. Reader response was better than any polished version.

That last one is the trick. Honesty about the edges of your knowledge is the strongest signal that the rest of your numbers are real.

Get the quote without asking for a testimonial

Founders hate the testimonial ask. It feels like soliciting praise. Solution: don't ask for praise. Ask for a fact.

Send this, verbatim: "Hey — writing up the fix we did on the connection pool issue. Two questions. One, before we changed it, what did the on-call rotation look like? Two, after, what changed? One sentence each is fine, and I'll send you the draft before it goes live."

You'll get back something like: "Before, we were paging twice a week on customer-facing 500s. After, I haven't been paged in six weeks." That's a testimonial. You didn't ask for praise; you asked for a schedule. Facts are easier to give than flattery, and they land harder.

If they say no, publish anyway with the customer anonymized ("a 40-person B2B SaaS with about 200 requests/sec peak"). Real numbers, no name. Still converts. The number is the credibility; the name is the bonus.

Where this fits in your funnel

Placement matters more than polish. I put one case study at the bottom of every pricing page and one in the first reply to any inbound lead. That's it. No gated PDF, no "download our whitepaper." If someone has to give you an email to read proof, they assume the proof is weak.

Format the page as plain HTML. No JavaScript carousel. One curl should return the whole thing:

terminal bash (80x24)

$ curl -s https://yoursite.com/case-studies/connection-pool | wc -w
  1240

Twelve hundred words of substance. That's the asset. It'll outlive your next three landing page redesigns.

One more thing while you're here: there's now an AI Contact Hotline where agents can tip off authorities about misbehavior AI agents now have a place to snitch. Read that twice. The systems you run are starting to have their own paper trail, whether you write it down or not. Your case study is the version of that trail with your name spelled correctly on it.

Do it this week

Pick one customer you fixed something real for in the last 90 days. Open a text file. Write the four headings. Paste in the commands you actually ran. Email the customer the two questions. Publish Friday.

That's the whole playbook. No committee, no brand review, no "let's circle back on tone." The founders who win are the ones whose proof is a git log, not a positioning statement. We build and run these systems every day at Claw Way, and the writeup is never the hard part — the work is. You've already done the work. Now write it down.

References

AI-assisted, curated for Side Quest Studios.