We Built Billing Before We Built Features

The most unpopular opinion in startups

Here’s something you won’t hear at a startup meetup: we wired up billing on day three.

Not the pricing page. Not the “we’ll figure out monetization later” hand-wave. Actual subscription syncing, payment guards, and usage tracking. Before we had half our features built.

Every mentor, every blog post, every Y Combinator video says the same thing: don’t worry about monetization yet. Just get users. Revenue can come later.

We respectfully disagree.

Why billing first is actually user-first

The argument against early billing is that it “distracts from building.” But here’s what actually happens when you defer billing:

You build an AI platform where every user gets unlimited access. You acquire users who love the unlimited access. Then one day you flip the switch and tell those users they need to pay. Some will. Most won’t. And the ones who stay are the ones who happened to be using features that fit within your hastily designed pricing tiers.

We didn’t want that future.

By building billing on day three, every feature we added after that point was designed with awareness of what tier it belonged to. “Should this be in the free tier or pro?” became a natural question during development, not a painful retrofit six months later.

What day three looked like

November 24, 2025. Three days after the first commit. The product had chat, file management, workspaces, and basic agent capabilities. Here’s what we added:

Subscription syncing via RabbitMQ. Our billing service sends subscription status updates. The dashboard receives them and knows exactly what plan each user is on. Real-time. No polling. No stale data.

Billing guards on protected routes. Try to access a pro feature without a pro subscription? You get a clean modal explaining the limit and how to upgrade. Not a crash. Not a blank page. A designed experience.

Credit tracking. We track AI usage per user. Not because we want to nickle-and-dime people, but because predictable costs require predictable usage tracking. OpenClaw users report spending $50-750/month with zero visibility into where the money goes. We decided that would never be our story.

Annual subscription handling. Because we knew some users would want to pay annually, and adding that “later” always means adding it badly.

The compounding benefit

Here’s what most people miss about billing-first: it compounds.

When we added image generation two weeks later, the billing guard was already there. We just tagged image generation as a pro feature and it worked. No additional billing code.

When we added the skills marketplace, same thing. Free users see a “Pro” badge on premium skills. No new billing logic needed.

When we added background task execution, the sandbox execution counter was already tracking usage. We just set the limits per tier.

Every feature we’ve built in the last 80 days inherited billing awareness for free. That’s the compounding benefit of building the foundation early.

The real cost of “later”

We’ve watched other startups in our space struggle with this. They build beautiful products with unlimited everything. Then they try to add billing and discover:

• Their database doesn’t track usage per user
• Their API doesn’t distinguish between free and paid operations
• Their frontend has no concept of “you can’t do this on your plan”
• Their users feel betrayed when limits appear

Retrofitting billing into a product that was designed without it is one of the most expensive things a startup can do. Not in money — in architectural debt and user trust.

$0 to $40 per month

Our pricing ended up simple: Free ($0), Pro ($15-20), Power ($40), Team ($25/seat). Each tier has clear limits. Each limit is enforced by code that was written on day three and has been running ever since.

Users on the free tier know exactly what they get. Users on paid tiers know exactly what they’re paying for. Nobody gets a surprise bill.

That’s not because we’re generous. It’s because we built billing before we built features.