Running your own billing on your own tool is the most honest QA there is
Today I did the thing every dev-tool founder eventually has to do: I put my own product underneath my own company.
Some context. I build BuildBase - a React/Next.js SDK that handles the SaaS backend nobody wants to rebuild every time: auth, workspaces, usage-based billing with quotas and overages, notifications, feature flags, i18n. I've been running it in production on five of my own products for a while (PlugNode, AgentCenter, Imejis, RemoteWait, LinkTracer), so it wasn't theoretical. But the one place it wasn't running was BuildBase itself. The marketing site, the dashboard, the admin panel - my own user and subscription management - were the last holdout.
So today I wired my own SDK into all three. BuildBase now manages its own users, subscriptions and billing through the exact same SDK I hand to every other developer.
The uncomfortable part is what it exposed. You can hand-wave rough edges on a side product. You cannot hand-wave them when it's your actual customers and your actual billing path. Within the first hour I found three things I'd quietly been avoiding for weeks - small stuff, but the kind of small stuff that erodes trust if a real customer hits it first. Putting your own money-path on your own tool is the most honest QA you can run.
I'll be straight about where this is: it's React/Next.js only, and I'm building it alone. It is not Clerk-mature. But "I run my own company on it" is a very different sentence than "I run a demo on it," and I wanted to be able to say the first one.
If you sell developer infrastructure and you're not running your own critical path on it yet, I'd push you to. It's uncomfortable in the right way.
Site's at https://buildbase.app if you're curious. But mostly I'm curious about you - anyone else here run their own product on their own tooling? What did it force you to fix that you'd been ignoring?
I feel like there's a big difference between building for users and depending on your own product every day. Once your own business relies on it, every rough edge becomes impossible to ignore. Congrats on crossing that line, it says a lot more than any feature list could.
yes — i build a framework in the same spirit (the boring 80%: auth, multi-tenancy, billing, audit) and run it on my own products, a credit/mortgage planner and a status-page tool. dogfooding the money-path forced exactly the stuff tests never hit: proration on a mid-cycle plan change, and the ugly one — a dropped/retried billing webhook that leaves "provider says paid" out of sync with "entitlement says no access." the customer pays and gets nothing, and you only catch it when the customer is you. tests cover the create-path; your own billing exposes the state-transitions. "i run my company on it" > "i run a demo on it" is the right bar — respect for shipping it solo.
"Putting your own money path on your own tool is the most honest QA" landed for me, though in my case, it wasn't the checkout that exposed things, it was reading the numbers afterward. My payment provider quietly writes two paid rows per customer (a zero-dollar trial activation, then the real charge a few days later), so my revenue query was double-counting every signup for weeks. Nothing looked broken. The MRR was just wrong, and flatteringly so.
I only caught it because the number felt too good, went digging, and found I had to filter on net amount above zero. The money path did not fail loudly; it lied quietly, which is worse. Were your three things in the checkout flow itself, or in the reporting after?
"Dogfooding your billing path" is the sharpest version of dogfooding because money is where hand-waving stops. Nobody tolerates their own broken checkout. And the honesty (not Clerk-mature, solo, React-only) builds more trust than a polished pitch would.
The insight worth pulling into your marketing: "I run my own company on it" isn't just better QA, it's your differentiator against Clerk. You can't out-mature Clerk, they have too big a head start. But Clerk doesn't run its own billing on Clerk the way you run BuildBase on BuildBase. Your edge isn't feature parity, it's that you feel every rough edge before your customers do, because it's your money path too. A wedge Clerk structurally can't claim. Lead with it.
The tension to watch: dogfooding one company is powerful proof but still n=1. The three bugs you found in an hour are the good news and the warning. If an hour of billing surfaced three, a developer betting their SaaS on it is doing the same math. So the story isn't just "I run mine on it," it's "I run mine on it AND here's what broke and how fast I fixed it." For a solo pre-mature tool, responsiveness is the trust signal, more than the feature list.
To your question, what dogfooding always forces: the edge-case paths you skip because the happy path demos fine. Billing especially, the failed-card, mid-cycle-upgrade, refund, proration cases nobody builds until a real customer hits one.
What are the three you found? Specifics would make this post land harder than the principle.