How we’re rewriting our problem section for buyers: behind the scenes

A few weeks ago I got on a call with the CTO of a mid-size fintech company. He’d visited clawmetry.com after seeing the GitHub repo, scrolled through the page, and found the section that shows our detection data: seven sessions flagged out of 68 total, 21% of all spend, one developer’s laptop, four months. He had one question before agreeing to evaluate ClawMetry for his team.

“This data is from one person. I have 60 developers running maybe 200 agents a day. What does your detection rate look like at that scale, and what’s my risk exposure if I don't have this?”

The page had no answer. I gave him the honest answer on the call (the extrapolation holds, and at 200 agents we’d expect 8–10 stall events per day, each costing $20–$200 in wasted compute), and he booked a trial. But he shouldn’t have needed a call to get that answer. It should have been on the page.

This is the fourth post in our CXO messaging audit series. We covered the hero section, the pricing section, and the solution section. The problem section — the section that establishes why this exists before showing what it does — is the one we’ve spent the least time on. It shows. Here’s the audit.

What the section actually says

The current problem section is labelled “Measured, one install, four months.” The headline reads:

Then there’s a split panel showing one expensive session that was never flagged ($171, 1,700 turns, writing code the whole time) and seven flagged sessions ($175 total, 4% of sessions but 21% of all spend). Below that, a reassurance: “Detectors warn. They do not act. All seven of those sessions ran to completion.”

Every word is accurate. The section works well for a developer evaluating ClawMetry for their own use. It answers the first question a practitioner has: will this constantly interrupt my work? The answer is no, only 4% flagged, and only when there’s a real signal.

But a Head of Platform or CTO isn’t asking will this interrupt me. They’re asking: what is my risk exposure right now, how does this scale to my team, who has authority to act, and what’s my audit trail? The section answers zero of those four questions.

The five-point gap audit

1 One laptop, four months — sounds like a beta, not a baseline

The section header “Measured, one install, four months” is doing something subtle and counterproductive. It’s signalling intellectual honesty (we show our actual data, not a curated aggregate) while simultaneously undercutting the section’s job, which is to establish that the problem is real and significant at enterprise scale.

A developer reads “one install, four months” and thinks: honest founder, real numbers, I trust this. A platform buyer reads the same phrase and thinks: this is one person’s anecdote, not evidence for a 60-developer deployment.

The intellectual honesty is right. The framing is wrong. The fix isn’t to hide the single-developer origin of the data. It’s to also show what the data predicts at fleet scale. “7 of 68 sessions flagged” is a 10% detection rate. At 200 daily agent sessions, that’s 20 stall events per day, each potentially burning $20–$200 in wasted compute. That’s the number a CTO needs to justify the purchase. It’s implied by the data on the page; it’s never stated.

2 “Stall” doesn’t map to a budget line item

The headline calls it a “stall.” Our detection logic calls it no_progress, repeated_tool_failure, and stuck_loop. These are accurate technical terms that describe the mechanism. But a CTO translating this into a budget conversation needs a dollar figure, not a mechanism label.

The 21% figure is buried in the split panel. The problem section should lead with the dollar translation: 21% of your agent compute budget is going to sessions that aren’t producing anything. At $5,000/month in agent costs, that’s $1,050 you could recover.

We showed this calculation in the productivity gains post. It never made it onto the landing page. The problem section is exactly where it belongs.

3 “Detectors warn. They do not act.” answers the wrong question for a platform buyer

This line is one of my favourite pieces of copy on the site. It addresses the fear that an observability tool will be too aggressive: interrupting productive sessions, flagging work that’s just slow, killing the agent mid-task. That’s a real concern for a developer using ClawMetry alone.

But a Head of Platform reads “they do not act” and hears: so who does act? The natural follow-up for a platform buyer isn’t “good, I don’t want interruptions” — it’s “OK, so how does this integrate with my PagerDuty rotation? Who on my team gets the alert? What’s the escalation path if the agent owner doesn’t respond in 10 minutes?”

ClawMetry has answers to all of those questions. The Slack and PagerDuty alert integrations are real. The per-agent ownership model (one team lead per agent, alert goes to them first) is in the product. Budget alerts that fire when a session approaches a threshold you set are shipped; automatic hard-stop enforcement is on the roadmap. None of that appears anywhere in the problem section. “Detectors warn” leaves the governance story half-told for the exact buyer who cares about it most.

4 The section frames cost as a savings opportunity, not a risk event

$175 in flagged spend sounds like a minor annoyance. Over four months on one developer’s machine, that’s true. But the problem section is supposed to establish the business case for observability, not just the efficiency case. The efficiency case (save 21% of compute) is real. The risk case is more urgent.

An agent stuck in a loop doesn’t just waste money. It can corrupt outputs. A code generation agent that loops on the same failing test for three hours might commit partial, broken changes. A data pipeline agent caught in a retry loop might write duplicate records. A customer-facing agent stuck on a null API response might silently return wrong answers for eleven days, as it did in one of the three agent fires post.

The problem section talks about wasted compute. It should also talk about corrupted outputs and silent wrong answers, because that’s what makes the CISO and Head of Risk care. Cost is a CFO conversation. Silent failures affecting customer-facing output is a CTO conversation. We need both.

5 The problem frame is individual, not organisational

Every element of the current section speaks to one person: one install, one laptop, one developer’s four months of data. The hero already established individual use case (“runs on your machine”). The problem section is where a buyer should start to understand that this scales to their whole team, that visibility across 60 developers’ agents is the same product as visibility into one developer’s agents, with a fleet view layered on top.

There’s no organisational framing anywhere in the problem section. The phrase “your team” appears zero times. “Fleet” appears zero times. “Organisation” appears zero times. A platform buyer has to do all the mental translation themselves: “I assume this scales to teams, let me keep reading to find out.” Half of them won’t.

Current single-developer framing vs. rewrite draft showing fleet-scale risk translation, governance path, and organisational scope. The data stays the same; the frame shifts from individual curiosity to organisational risk.

What the rewrite will say

Same data. Different frame. Here’s the working draft.

The split panel stays — it’s doing the right thing showing the expensive productive session vs. the flagged sessions. But the label changes from “Measured, one install, four months” to something that signals both the honesty of the data and its relevance to a team:

And the reassurance line gets expanded to answer the governance question a platform buyer is actually asking:

That last version is longer. It trades brevity for completeness on the four questions a platform buyer actually has. The individual developer visiting the page doesn’t need the escalation path explained; they’ll skip it. The CTO evaluating a company-wide deployment needs it answered before they keep reading.

The final addition is a fleet-scale line beneath the split panel:

I’m not fabricating that number. It’s a direct extrapolation of the data already on the page, with the median cost per session added. We could show it as a slider (“how many agents do you run?”) but I’d rather ship the static version first and add the slider if it converts.

What stays the same

The core data stays. The split panel stays. The intellectual honesty about it being one machine, four months, stays — that credibility is worth keeping. The reassurance that detectors don’t act without human intent stays; it just gets extended to answer the follow-up question.

What changes is the frame: from “will this tool annoy me?” (individual developer concern) to “what is my organisation’s exposure, and how does this tool give me control?” (platform buyer concern).

The visual design stays. One small structural addition: a row beneath the data panel that translates the percentage into a fleet dollar figure. That’s one new element. Everything else is copy changes in place.

Why every section in this series ships as a post before it ships as code

The hero, pricing, and solution posts in this series all preceded the actual page changes by two to four weeks. That lag is intentional. Publishing the audit forces three things:

First, it forces me to be specific. “The problem section needs work” is easy to say. Writing down the five exact gaps and the draft copy that fixes each one is much harder. I can’t publish vague criticism under my own name. The post quality is a forcing function for the thought quality.

Second, it surfaces the counter-argument. The current problem section headline, “It flags agents that stall, not agents that cost money,” is good copy. It’s punchy, specific, and distinguishes ClawMetry from tools that just alert on cost. I don’t want to lose that distinction in the rewrite. The post makes me articulate what’s worth keeping, not just what’s wrong.

Third, it creates accountability. If I don’t ship the rewrite, this post sits as public evidence that I identified the problem and didn’t fix it. That’s a small but real motivator.

The pattern we’ve settled into: audit post ships Monday, rewrite PR opens Thursday, ships to production the following week. The posts have been good for distribution too — the solution section audit was picked up on a few Slack groups for platform engineering leaders, which is exactly the audience that section needs to reach.

The pattern: problem sections are written for practitioners, not buyers

Every developer tool that grows from a solo practitioner’s open-source project hits the same wall. The problem section is the founder saying: here’s the pain I felt, here’s the evidence I collected, here’s what I found. It’s authentic. It’s compelling to other practitioners. It’s almost completely useless to a platform buyer who has never felt that specific pain themselves but is responsible for preventing it at scale across 60 people.

The developer audience reads the problem section and nods: yes, I’ve had a session do exactly that. The CTO audience reads the same section and asks: what does this mean for my budget justification email? Those are different questions, and right now we only answer the first one.

We grew to 230K+ installs on developer word-of-mouth. The problem section helped that — practitioners recommended ClawMetry to other practitioners because they saw their own experience reflected in the data. That flywheel worked. But the next flywheel is platform buyers recommending ClawMetry in their annual software reviews, budget conversations, and vendor evaluations. That flywheel needs the problem section to speak to an organisational risk frame, not just an individual frustration frame.

The rewrite is that shift. Same data, same honesty, same specificity. Translated into the language of a person who writes budget justification emails.