Why I'm building Refract after five years at Loom

Invisible boundaries and the architecture I wish I'd had.

TL;DR

• After five years at Loom — including leading billing through the Atlassian acquisition — I left knowing that billing is where business strategy hits the technical ceiling.
• The root cause isn't your provider. It's invisible boundaries between billing, permissions, and pricing logic.
• Refract makes those boundaries explicit from day one: billing and RBAC as first-class features, vendors as swappable dependencies, checkout you actually own.
• If you're a solo technical founder choosing a stack before billing gets complex, this is the post I wish I'd read first.

After five years at Loom, including leading billing through the Atlassian acquisition, I left with one conviction:

Billing is where business strategy hits the technical ceiling.

Every new pricing model, packaging experiment, or large deal with custom terms eventually becomes a software problem. How well your architecture handles that moment determines whether pricing feels like a product decision or a system-wide bet. That's why I'm building Refract.

What I kept seeing at Loom

The pattern repeated constantly. A pricing change would look small in planning — a new tier, a usage cap, a grandfathering rule — but would eventually touch entitlement systems, reporting pipelines, checkout flows, and vendor integrations that nobody expected. The engineering work wasn't hard because the business idea was complex. It was hard because the architecture had forgotten where the boundaries were. Billing debt is what you pay when those boundaries are gone.

A seemingly simple pricing experiment could require changes across checkout flows, entitlement logic, invoicing, reporting, and customer support tooling — five systems before you've even measured whether the experiment worked. We ran parallel experiments on top of hacky business logic just to buy time. We paid for that in months of on-call incidents and stressful deploys.

In March 2025, I was let go. I'm not sharing that for sympathy. I'm sharing it because it's the price of learning what I would do differently next time.

The root cause

For a long time I thought the answer was better execution. Better testing. Better processes. Those things help, but eventually I realized we were fighting the architecture itself.

The problem wasn't Stripe. The problem wasn't the backend framework. The problem was that billing, permissions, and pricing experiments all share the same business-critical boundaries — and in most SaaS stacks, those boundaries are invisible. When they're invisible, every change is risky not because it's complex, but because nobody is sure what it touches.

That's the thing worth fixing.

The architecture I built because of that

Most SaaS stacks start by optimizing for shipping features. Refract starts by optimizing for changing pricing. Those sound similar until the business grows.

Billing and RBAC are first-class features, not afterthoughts. Stripe stays a swappable dependency, like analytics or email. Hard module boundaries and explicit contracts turn vendors into implementation details. Stripe hosted pages are the right call for an MVP — they become a ceiling when you need to own the funnel, run experiments, and stop losing visibility on the page that actually makes money.

This is not just about lock-in. It is about legibility. Clear edges shrink the context needed to make safe edits, for both senior engineers and LLMs. You can move from per-seat to usage-based pricing without betting the whole system on one deploy.

The architectural shape behind this — why a thick backend over a Next.js monolith — is the subject of Why I chose a Node.js monorepo over Next.js. The vendor-coupling argument goes deeper in The hidden revenue tax of vendor-coupled SaaS architecture. The full implementation map is at docs.userefract.io.

Why Refract exists

I don't know if Refract succeeds. I do know I never want to treat a pricing experiment like open-heart surgery again.

I'm not asking you to agree with every architectural choice I've made. I'm asking you to take billing and access control seriously before they become the story your company tells about itself. When your business logic is hostage to a provider's roadmap or a brittle architecture, you aren't really in control.

Refract is my attempt to put that seriousness into something you can actually ship. If any of this resonated, userefract.io is where it lives. I'll keep writing from the part of the product where the receipts are real.