← Back to blog
· BoxBilling Team

Why We Rebuilt BoxBilling From Scratch

announcement open-source architecture story

BoxBilling used to be a PHP billing panel for web hosting. A WHMCS alternative. It had its moment — a decent community, some traction, a recognizable name in the hosting world. But let’s be honest: it never broke through. The codebase was PHP 5-era patterns held together with jQuery UI and MySQL queries. It worked, but it wasn’t going anywhere.

We could have tried to modernize it. Rewrite the frontend. Upgrade to PHP 8. Bolt on an API. We’ve seen other projects try that — incremental rewrites that take years and end up as Frankenstein codebases, half legacy and half modern, fully neither.

We didn’t do that. We burned it down and started over.

Why not just fork Lago?

Fair question. Lago exists, it’s open source, and it does usage-based billing. We respect what they’ve built. But when we looked at building on top of it, the fit wasn’t right.

Lago is Ruby on Rails. It’s a solid framework, but it’s not where we wanted to live. We wanted Python — the FastAPI ecosystem, async-native from day one, proper type hints, and direct access to the ML/AI tooling we planned to integrate. Billing is a data-heavy domain. Python is where data tooling lives.

Beyond the language, we had different architectural opinions. Lago gives you an API. That’s great if you have a frontend team ready to build a customer portal. Most teams don’t. We wanted to ship both the billing engine and the UI components to go with it — drop-in web components that give your customers a billing portal without you writing a single line of frontend code.

And then there’s AI. We wanted revenue forecasting and anomaly detection built into the core, not bolted on as an afterthought. That’s hard to do in a fork. It’s natural in a ground-up build.

What we kept: the name

boxbilling.com has domain authority. People search for “BoxBilling” and find us. The name literally means “billing” — it still fits, maybe even better now than before.

Everything else is new. Zero lines of PHP. Zero shared architecture. Different language, different database, different market, different product. Same name, completely different animal.

The new stack

Here’s what bxb runs on:

  • Python 3.12+ / FastAPI — async, OpenAPI-native, auto-generated docs
  • SQLAlchemy 2.0 — async ORM with migrations via Alembic
  • PostgreSQL — billing data: customers, invoices, subscriptions, wallets
  • ClickHouse — event streaming, usage metering, analytics at scale
  • Pydantic v2 — Rust-powered validation for every request and response
  • bxb-elements — Lit-based web components, framework-agnostic
  • TimesFM 2.5 — AI-powered revenue estimation and churn prediction

A quick taste of what the API looks like:

from bxb import BxbClient

client = BxbClient(api_key="bxb_live_...")

# Create a usage event
await client.events.create(
    customer_id="cust_8a3f",
    event_name="api_call",
    properties={"model": "gpt-4", "tokens": 1523}
)

# Get current invoice for a customer
invoice = await client.invoices.current(customer_id="cust_8a3f")

That’s it. No XML. No SOAP. No 47-step configuration wizard. Type-safe, async, and documented automatically via OpenAPI.

What bxb does now

This isn’t a billing panel for hosting anymore. bxb is billing infrastructure for SaaS:

  • Usage-based billing — meter API calls, storage, compute, tokens, whatever you sell
  • Subscription management — plans, upgrades, downgrades, trials, pauses
  • Hybrid models — subscription base + usage overages (the model every AI company needs)
  • Invoicing & payments — generate invoices, connect payment processors
  • Customer wallets — prepaid credits and balance management
  • Coupons & promotions — percentage, fixed amount, duration-based
  • Multi-currency — bill in your customers’ currencies
  • AI estimation — revenue forecasting, churn prediction, and anomaly detection via TimesFM integration
  • bxb-elements — drop a <bxb-billing-portal> web component into your app and your customers get a complete billing UI

That last one matters more than it sounds. Most billing APIs leave you to build the customer-facing UI yourself. bxb-elements gives you a billing portal, invoice views, payment method management, and usage dashboards as framework-agnostic web components. React, Vue, Svelte, plain HTML — doesn’t matter.

The market we’re in now

We’re not competing with WHMCS anymore. We’re in the SaaS billing infrastructure space alongside Lago, Stripe Billing, Chargebee, Recurly, Zuora, and Orb.

Our angle is straightforward:

  • Open source (AGPL-3.0) — run it yourself, audit the code, contribute
  • Self-hostable — your billing data stays on your servers
  • AI-powered — forecasting and anomaly detection aren’t premium add-ons, they’re built in
  • UI included — bxb-elements means you ship a billing portal, not just an API
  • No per-event fees — meter billions of events without per-event pricing eating your margins

For teams that want managed hosting, we offer that too — ClickHouse-backed event processing with EU and US regions.

What’s next

We’re heads-down on payment processor integrations, webhook reliability, and expanding bxb-elements with more components. The roadmap is public and driven by what the community actually needs.

If you’re building a SaaS product and billing is either a pain point or a looming one, take a look:

BoxBilling is back. It just doesn’t look anything like it used to — and that’s the point.