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

Last month a VP Engineering at a fintech company scheduled a call after visiting clawmetry.com. She'd scrolled through the "What you get" section (eight feature cards, carefully written, accurate) and had one question: "Which of these is the chargeback feature?"

I knew what she meant. She's running 20 developers across 3 teams. Every team shares an Anthropic API key. At the end of every sprint, her CFO asks which team spent the most on AI. She needs to attribute token spend by team, by agent, by environment, and show it in a report her finance lead can read without a terminal.

The feature exists. Card six in our grid says "Know which agent spent it." She missed it entirely. That's on us, not on her.

This is the third post in our CXO messaging audit series. We covered the hero section (June) and the pricing section (June). The solution section (the "What you get" features grid) is the middle of the page where a buyer who survived the hero comes to confirm they're in the right place. Right now, it confirms the wrong thing.

What the section actually says

Here's the current copy, verbatim:

Then there are eight feature cards, each with an icon, a headline, and one sentence. They're accurate. They're in no particular order of buyer priority. The section is designed as a feature discovery grid for a developer who's already curious: scan the icons, see what resonates, proceed to install.

That's a fine design for a developer. For a VP Engineering deciding whether to budget $X/month for a team of 20, it's a grid of equal-weight items with no narrative thread. The two things she cares most about, per-team cost attribution and data residency, are buried at positions six and eight.

The five-point gap audit

1 "Built because we needed it" is a developer origin story, not a buyer value prop

The section subheadline — "Built because we needed it. Now you don't have to build it yourself." — is founder authenticity copy. I love it for what it is. It signals that ClawMetry solves a real problem, built by practitioners, not a VC-funded observability tool that added an "AI agents" page in 2024.

But a VP Engineering writing a budget justification email doesn't lead with "they built it because they needed it." They lead with: "ClawMetry gives us per-team cost attribution, a full audit trail, and loop detection across our entire agent fleet, without touching agent code." Those are the three sentences that appear in the CFO email. Not "built because we needed it."

The origin story belongs in the About page. The solution section should open with what it means for the buyer's org.

2 Eight cards at equal visual weight means the buyer reads zero of them

The killer feature card at the top is the one exception: "Catch the agent that's about to spend $400. Before it does." That card has a badge ("The big one"), a longer description, and screenshots. A buyer reads it. Then they hit the eight-card grid and their eyes glaze.

The problem isn't the number of features. The problem is that every card looks equally important. There's no visual or narrative signal that says: this one is why your CISO approved us, this one is why your CFO will renew, this one is why your on-call engineer won't wake up at 3am.

Enterprise observability tools have taught buyers to expect two tiers of feature presentation: the three things that close the deal, then the full list for the technical evaluator. Our grid skips the first tier entirely.

3 Chargeback reads as monitoring. It's actually a finance deliverable.

Card six: "Know which agent spent it: per-agent, per-session, per-model, per-tool. Know what you're spending before the invoice shows up."

That's good copy for a developer. For a finance-facing platform buyer, the job-to-be-done isn't knowing what you're spending. It's producing a report that a VP of Finance can read, a team lead can dispute, and an ops manager can use to set next quarter's budget. The word "chargeback" never appears. The phrase "cost attribution by team" never appears. "Export to CSV for your finance team" never appears.

We have this functionality. The audit endpoint returns per-session, per-model breakdowns. The usage tab has export. But a buyer landing on the feature card has no reason to believe it.

4 The OTel card is buried at position eight, but it's often the enterprise dealmaker

Card eight: "OpenTelemetry-native: send your traces anywhere, no lock-in."

For an enterprise with an existing Datadog or Grafana deployment, "OTel-native" is the feature that makes ClawMetry a yes instead of a maybe. It means ClawMetry doesn't displace their existing observability stack, it enriches it. Agent sessions flow into Datadog like any other service. No parallel dashboard fatigue. No re-training the on-call team.

That's a procurement-unlocking argument. A CTO evaluating five tools will say "the OTel-native one fits our existing stack" and the evaluation is over. But it's card eight, after two cards about cron jobs and task systems that don't land as cleanly for an enterprise buyer.

5 The data residency story is absent

The features grid has no mention of where data lives, who holds the keys, or what the compliance story is. This is the biggest gap.

Our moat (the thing that wins deals against LangSmith and Datadog in regulated industries) is local-first compute on DuckDB with end-to-end encrypted cloud sync. Agent transcripts never leave the customer's machine in readable form. The encryption key lives with the customer. ClawMetry's cloud sees ciphertext, not agent conversations.

That story belongs in the solution section because it's a dealmaker in financial services, healthcare, defense, and any company that's been through a data breach. It's not a footnote. It's a reason to pick us over a hosted SaaS observability tool. Right now a buyer has to reach the FAQ or the pricing page to find it. By then, half of them have already decided they'll "check with security later," which means never.

Current features grid (developer-ordered) vs. buyer-ordered rewrite draft. The OTel and data residency cards move to positions 1 and 2; cost attribution gets explicit chargeback language.

What the rewrite will say

Here's the working draft. Not final; same as the hero and pricing posts, I'm publishing it before shipping so there's a commit to hold us accountable.

That's the opener. Then the killer feature card stays exactly as it is, it works. What changes is the grid beneath it.

The reordering logic is buyer-priority, not feature-discovery:

1. Data residency first: the feature that unlocks regulated-industry evaluations. Local-first compute. E2E encrypted cloud sync. Your key, your data.
2. OTel-native second: the feature that fits existing enterprise stacks. Slots into Datadog, Grafana, Honeycomb without displacing them.
3. Cost attribution / chargeback third: renamed from "Know which agent spent it" to "Per-team cost attribution and chargeback reports." Explicitly mentions CSV export and finance-readable breakdowns.
4. Audit trail fourth: "What happened in that agent session last Tuesday?" maps to compliance, incident review, and the CTO's post-mortem. Not just dev curiosity.
5. Loop detection fifth: the $400 card, but extended to fleet scope: "Across 20 agents. In real time. Page your on-call before the loop hits $50."
6. Then the remaining cards: stuck agent diagnosis, cron health, stack compatibility. Still there, just below the fold for the technical evaluator who wants the full list.

The feature set doesn't change. The vocabulary shifts from what it does (monitor, track, flag) to who it serves and what they need (finance lead, CISO, on-call team, CTO's post-mortem).

What stays the same

The killer feature card is right. "Catch the agent that's about to spend $400. Before it does." is sharp, specific, and works for both a developer and a buyer. It stays at the top and stays unchanged.

The eight features themselves all stay: every card describes something we actually ship. The rewrite is a reorder + vocabulary update, not a feature deletion. The technical depth in each card body stays in for the developer evaluator who scrolls past the top three.

The visual design (the icon grid, the card layout) stays. The only structural change is adding a "data residency" row above the grid that answers the CISO's question in one paragraph before they have to ask.

Why we publish the audit before we ship the rewrite

Same reason as the hero and pricing posts: the audit is cheap, the rewrite takes a week, and publishing the audit first means it actually ships.

But there's a second reason specific to the solution section. Features grids are written incrementally. Card one was added when we shipped session transcripts. Card six was added when we shipped the usage breakdown. Nobody ever stepped back and asked: if a VP Engineering lands here after surviving our hero, what is she looking for in this exact order?

Doing the audit forces that question. The answer is not "the order we shipped features." The answer is: data safety first (does this pass my CISO?), then stack fit (does this slot into what we already have?), then cost visibility (can my finance team use this?), then operational safety (will this wake me up at 3am instead of the loop?). Everything else is a bonus.

The grid we have answers those questions, but in the wrong order, with the wrong vocabulary. That's fixable in a PR. This post is the ticket.

The pattern: features grids are written for builders, not buyers

Every developer tool with enterprise ambitions hits this wall. The features grid gets built by the person who shipped each feature. Each card is the smallest accurate description of one capability. The order is chronological, or alphabetical, or whatever felt right the day it was added.

That's not how a buyer reads it. A buyer comes in with three questions (is this safe, does it fit our stack, can I justify the spend?) and scans for answers in the first 30 seconds. If those three questions aren't answered in the first three cards, the buyer exits and the product never gets evaluated for its actual depth.

Our solution section has the answers. "Know which agent spent it" is the chargeback answer. "OpenTelemetry-native" is the stack-fit answer. The data residency moat is the safety answer. The rewrite isn't adding content; it's making what we already ship legible to the person writing the budget justification email.

We grew to 120K+ installs on developer word-of-mouth. That's the OSS flywheel working. But the cloud product (multi-node fleet dashboards, per-team attribution, Slack/PagerDuty alerts, approval workflows) converts when a platform buyer can read a features section and see their own problems reflected back. The rewrite is that mirror.