For 15 years, I was an engineer in the US startup ecosystem — scaling systems, shipping fast, and watching the same mistakes repeat themselves across every company I worked at.
The worst one: billing logic hardcoded so deeply into the product that changing a pricing tier required more than a sprint, with hard to predict side-effects, leading to stressful incidents. Subscription state without clear owner. Plans that couldn't be migrated without risk of double-charging real customers or having them loose service.
I saw this up close as Billing Tech Lead at Loom — through the Atlassian acquisition. That acquisition is one of the most complex billing transitions a SaaS company can go through. I was in the middle of it.
The Big Reset: Relocating to Porto
In July 2025, my family and I left California and moved to Porto, Portugal. With a toddler, being closer to family, creating memories, and getting more headspace felt the right move. A deliberate reset.
I started building Refract almost immediately — not because I had a brilliant new idea, but because I kept seeing the same problem and nobody had solved it well. Most boilerplates help you ship fast. None of them help you survive the pivot.
Why Refract?
Refract is a TypeScript SaaS foundation built around a constraint I stopped treating as optional: pricing changes, processors change, and the business model you launch with is rarely the one you run a year later.
The goal is not bragging rights about “no rewrites.” It is to keep the volatile parts at the edges—so subscription logic does not disappear into every feature, and plan changes do not become a scavenger hunt through your product layer.
Billing, separated from product logic
Plans and packaging live where they belong: outside the feature code that should not need to care how you charge. The intent is simple to say and expensive to do right: experiments with pricing should not cost a sprint every time the business learns something new.
RBAC and multi-tenancy in the model, not bolted on
B2B access arguments show up whether you are ready or not. Tenancy and permissions are treated as part of the data model so “we will fix enterprise later” does not quietly become structural debt.
Infrastructure behind real interfaces
Queues, cache, mail, and analytics sit behind typed seams with concrete implementations. Swapping a vendor should be a bounded project, not a rewrite of the domain.
Proof where it hurts
Tests and CI lean on the paths where mistakes are expensive—billing and auth—so refactors and pivots feel boring instead of reckless.
Local stack that behaves like production
Run make fresh-start and you get the full stack. Migrations and seeds run before the app starts. When that works on your machine, deploying to Railway is straightforward—not a separate project..
I'm building the foundation I wish I'd had at every company I worked at. If you're a technical founder who's been burned by architectural decisions made in a hurry, Refract might be what you're looking for.
https://userefract.io