The operating system thesis

A small-business owner once showed me her real tech stack. It was a Post-it note stuck to her monitor with six logins on it. A billing tool, a scheduling app, a CRM, an email platform, a spreadsheet that tied three of them together, and the password to the spreadsheet. Six bills a month. Six vendors. And one human being whose actual job, several hours a day, was carrying data from one of those tools to the next by hand.

That's not a software problem you fix by adding a seventh tool. That's the whole industry's default answer, and it's wrong. So here's what we believe instead: a business shouldn't run on a pile of rented apps it stitches together. It should run on one operating system, built for how it actually works, that we build and then run.

A tool does a slice. An operating system runs the work.

Every SaaS product is a slice. Billing is a slice. Scheduling is a slice. The CRM is a slice. Each one is fine on its own, and each one assumes the other slices are someone else's problem. The gaps between them become your problem. That spreadsheet on the Post-it note is the gap, made visible.

When we build for a business, billing, the customer app, the point of sale, the screens, the AI that answers people, and the integrations that move data are all parts of one system. They connect because we built the whole thing, not because someone bought six products and hoped a Zapier flow held the seams together.

Take Persistence Athletics, a gym that ran on Wodify plus the usual ring of tools around it. We didn't bolt on a feature. We replaced the platform. The custom Stripe billing engine (subscriptions, a Sunday billing cron, pause and resume, a payment-method gate, tax, auto-retry on failed cards, real invoices) shares a database with the member app, the EDSO programming engine, and PA Bot, the AI coach. So when a member asks PA Bot a question, it's reading the real program and the real logbook, not guessing. That only works because it's one system, not six that happen to be in the same building.

Why this was impossible last year, and isn't now

Be honest about the old math. Building a real operating system for one business meant an agency's six-month timeline and an agency's six-figure bill. No small business could justify that, so they rented slices and ate the gaps. The pile of tools wasn't anyone's preference. It was the only thing the economics allowed.

AI changed the math, and not by a little. We build with Claude Code and Codex, and the effect isn't that the code writes itself. It's that one focused team now ships what used to take a floor of engineers, in weeks, and keeps shipping after launch. The leverage is real and you can see it in what gets built:

• Persistence got a custom billing engine, 24 branded email flows, a native iOS app on TestFlight, an AI coach, a rules-based programming engine, and an automated class-video cataloger (local Whisper transcribes, Claude analyzes, a pipeline assigns and cuts clips). That's an agency-quarter of work, run by a small team.
• Craft Cannabis, a four-store cannabis retailer, runs a Windows POS, a CaseCard menu designer, and 31 Fire TV screens that update themselves silently every day, all pushed from one dashboard over VPN. One person updates 31 screens across four stores without leaving their desk.
• DRiV Fitness got a sync that makes PushPress and GoHighLevel behave like one system, matched by email, running unattended. It handed the owner about 40 hours a month back. In his words, a 'great help managing our gym's digital needs.'

None of these were possible to deliver at a small-business price two years ago. The thing that's new isn't the ambition. It's that the ambition is now affordable.

Build it, then run it

There's a quiet failure mode in custom software: the day it launches is the day it starts to rot. The agency ships, sends the final invoice, and disappears. Six months later the thing is brittle and nobody owns it. That's why 'we operate it' is the load-bearing half of this whole idea, not a footnote.

We run what we build in production. We monitor it, so problems get caught before customers feel them. We fix it fast, because we wrote it and know exactly where everything is. And we ship new features every week, so the system compounds instead of aging. The Persistence stack runs on a VPS we operate, with a split prod and dev setup so we test without touching live members. Craft's fleet gets daily silent updates the stores never think about. DRiV's sync restarts itself after a reboot. Software that's run stays alive. Software that's delivered and abandoned dies on a schedule.

You still own it

Operating it is not the same as holding it hostage. The business owns the system. Keep us running it, or take the keys whenever you want, with clean, documented, owned code. No per-seat fee, no vendor roadmap you can't change, no lock-in. When a gym wants a billing rule changed, we change it that week, because it's theirs and we're standing right there.

That's the thesis, and it's a simple one. Don't rent six slices and become the integration between them. Build the one system your business actually runs on, own it, and have someone keep it alive. AI is what finally makes that affordable for a business with a Post-it note on its monitor. Build it once and walk away, you get software that decays. Build it and run it, you get your business, on autopilot.

Wondering what one system would replace for you?