📣 I launched a reporting API that can't create reports

👋 Hey Friends!

Our first reporting API launched without the ability to create reports.

You can create dashboards through it. Reports, not yet. And that was on purpose.

On Wednesday I shared how to test something when there's nothing to click. Today is the part that comes before the test: deciding what to build in the first place, and what to leave out.

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.

If you're not using AI, you're spending 40 hours doing what they do in 4.

These 100+ Claude Code hacks fix that and help you ship 10x faster.

Sign up for The Code and get:

Claim your free playbook

My comfort zone as a PM is things I can see. Buttons, dashboards, flows I can click through and poke holes in.

In UI work, a missing feature can hide. Good design steers people toward what exists, and most never notice what doesn't. An API has nowhere to hide. If someone's first request is "create a report," it just isn't there.

I'd never planned an API before, and it's the exact opposite of what I'm used to. 😬 Almost every habit I'd built for frontend launches needed a replacement.

1. Scope by jobs, not screens.
There's no page to design, so we started with the highest-value things people need to do with their reporting data. Then we mapped that against what we could realistically ship.
If your scope doc lists things like "a settings page," rewrite each one as a verb, like "change who can see this report." Verbs are what an API is made of.

2. Close parity gaps before you get clever.
In UI work, "match the competition" can feel uninspired. With an API it's table stakes, because developers compare what they can do. We started with the gaps people would notice first.
If a competitor's API can do something yours can't, developers will notice that gap before anything new you add.

3. Make every cut a written decision.
Dashboards in, reports not yet. It was a deliberate tradeoff, and it's on our list.
If you cut something, name it as a known limitation in the docs. Someone will try it on day one.

4. Decide the guardrails the page used to handle.
In a UI, the screen quietly enforces who can see what and how fast someone can move. An API needs those decisions spelled out: permission scopes, rate limits, pagination, and max payload size.
If a user can't see a dashboard in the UI, make sure their API access can't pull it either. And plan limits with agents in mind, since they call far faster than a person clicks.

5. Run your beta with builders, not clickers.
A preview people click around in won't tell you much here. You need people who'll actually wire it into something.
If your beta list is mostly customers who love your UI, add partners or developers who'll build on it, and give them a sandbox.

6. Measure calls, not clicks, and give support the same view.
Page views don't exist here. Track calls by endpoint, error rates by type, and how long it takes someone to make their first successful call. Then make sure support can look up a specific request, not just a screenshot.
If a customer writes in saying "it didn't work," support should be able to ask for a request ID and see exactly what happened.

Pick a feature you own, or a tool you use every day. Write down the five jobs it lets someone do, as verbs. Then label each one shipped, parity gap, or deliberate cut.

If you can't say why something is a cut, it isn't a decision yet. It's just missing. Do it this week, not next sprint.

Your first API won't feel finished at launch, and it doesn't need to. Ship the jobs that matter most, close the gaps people will notice first, and write down everything you left out.

Reply and tell me: what's one thing you'd leave out of a v1 on purpose?

P.S. If you came from support or CS and assume platform or API work is out of reach, look at swap #6 again. Knowing exactly what support needs when something breaks is half the job. Let's talk through how to position that.
Book your next call with me here →

AI can write your code. It can't run your stack. Engineers who stay valuable know their terminal cold. The Code built the 100 CLI Tools, 2026 Edition, to showcase the stack top teams run on. Sign up and get the toolkit free, plus a 5-minute daily newsletter to stay 6 months ahead.

Claim your CLI toolkit