The Grave Mistake of Building Billing Before You Have Paying Customers
Grave mistake to make in the first year of building a B2B product: prioritizing license limitations and sophisticated billing systems before proving real value.
I've made this mistake. I've watched others make it. And it always costs months that early-stage products can't afford to lose.
TL;DR: Don't build license restrictions before you have demand to restrict. Don't build billing automation before you have customers to bill. These systems are for keeping order when demand already exists, not for preemptively locking doors on an empty house. Prove value first. Automate operations later.
The license restriction story
At one of my startups, we were so focused on preventing misuse that we forgot to focus on encouraging use.
We spent time building restrictions to prevent the same login from being used on multiple devices. Multi-device detection. Session management. Forced logouts. The whole system.
This was before we even had 10 active users.
We acted like people were going to fight over our product from Day 1. Like hordes of unauthorized users were waiting to exploit our generous access policies.
The reality: we couldn't even get people to use it on one device consistently. And here we were, building guardrails for a crowd that didn't exist.
The billing platform story
In another startup, we spent weeks planning and building a detailed billing system:
- Tiered usage pricing
- Credit systems
- Metering and limits
- Invoice automation
- Payment gateway integration
- Proration logic
Beautiful engineering. Sophisticated architecture. Completely premature.
Problem was: there was no one to bill. Not a single paying customer yet. We had built a toll booth on an empty highway.
The contrast: what success looked like
Compare that with another startup I was part of, which was far more successful.
We were sending manual invoices for many years. To some of the largest companies in the world. PDF invoices. Over email. Sometimes even word-of-mouth payment reminders.
It didn't matter. Because the product was working. Customers were happy. Revenue was growing.
Was it messy? Yes. Was it scalable? No. Did it matter? Not yet.
The billing automation came later, when the pain of manual invoicing was real. When we had 50+ customers and the finance team was drowning. That's when billing infrastructure made sense: to solve an actual operational problem, not a hypothetical one.
Why early-stage teams make this mistake
Three reasons, all understandable:
1. It feels "professional." Building billing and license systems feels like "real company" work. It feels like you're building something mature. Like you're preparing for success.
2. Fear of being exploited. "What if someone shares their login?" "What if they use more than they're paying for?" These fears feel rational. But they're solving for a world where people already love your product enough to share it. That's a good problem you don't have yet.
3. Engineering enjoys it. Billing systems, permission logic, and access control are interesting technical challenges. Engineers enjoy building them. So they get prioritized even when the business doesn't need them.
The timing principle
There's a clear sequence that works:
| Phase | Focus | Don't build |
|---|---|---|
| Pre-PMF (0-10 customers) | Value delivery, customer feedback, iteration | Billing automation, license restrictions, usage limits |
| Early growth (10-50 customers) | Repeatable sales, onboarding, retention | Complex tiering, metering, self-serve billing |
| Scaling (50+ customers) | Automation, self-serve, operational efficiency | Now is the right time for billing, licensing, access control |
License restrictions are for keeping order when there's already demand. Not for preemptively locking doors on an empty house.
Read that again.
If you're early, your problem isn't that people are misusing your product. Your problem is that not enough people are using it at all. Restrictions should come only after you have something worth restricting.
What to do instead in Year 1
Focus 100% on:
- Getting the product to solve the core problem exceptionally well
- Getting 5-10 customers who genuinely love it
- Understanding why they love it (or don't)
- Iterating fast based on real usage and feedback
- Making it easy to try, use, and get value from
Accept that you'll do things manually:
- Manual invoicing (it's fine, even at enterprise scale)
- Manual onboarding (it's better, actually, because you learn)
- Manual access management (just add users when they ask)
- Manual reporting (you'll learn what metrics matter)
Every hour spent on billing/licensing infrastructure in Year 1 is an hour not spent on proving value. And proving value is the only thing that matters in Year 1.
When it's time to build these systems
You'll know it's time when:
- Manual processes start breaking (invoices getting missed, access requests piling up)
- Customers start asking for self-serve options
- Your finance team is drowning in manual work
- You have enough customers that unauthorized access is actually a revenue concern
- Scaling is your biggest problem, not surviving
These are good problems. They mean your product works. They mean people want it. They mean you've earned the right to build operational infrastructure.
Building that infrastructure before these signals appear is premature optimization. And in startups, premature optimization kills.
The bottom line
If you're early, don't fear a little chaos. Fear building the wrong things too early.
A few shared logins won't kill your startup. A few manual invoices won't kill your startup. But spending three months on billing infrastructure when you should have been validating product-market fit? That might actually kill it.
Prove value first. Build systems later. The order matters.
How ProductResume helps
Strategic prioritization, knowing what to build when, is exactly what separates senior PMs from junior ones on a resume. If your bullets show you chose to focus on value delivery over premature infrastructure, that signals product maturity. Score your PM resume to see how your prioritization decisions read to hiring managers.