Why Replit Won't Eat My Booking Platform

A friend asked me last week whether Replit was going to eat Freebo. The question makes sense — every week there’s a new “describe an app and the AI builds it” tool. Replit, Lovable, Bolt, v0. The demos are stunning. Type a sentence, watch a working interface appear. Stripe wired up, schema laid out, click around, done.

So why am I still hand-writing migrations for a booking platform?

Because the demos stop right where my platform starts. The thing those tools are great at — the form, the layout, the CRUD glue — is the easy 20%. The 80% that matters in a reservation system is a list of invariants I’ve been writing in production code for months, and the moment a model tries to invent them on the fly, real money goes missing.

This post is about that 80%.

What the generic builders are actually good at

The pitch is real. You describe a marketplace for dog walkers and a working interface appears. The schema is reasonable. The buttons work. For an MVP — for anything where being wrong by a few percent doesn’t matter — these tools are genuinely useful, and dismissing them is its own kind of dumb.

They’re going to eat a lot of software. Most internal tools. Most CRUD apps. Most things that should have been a Notion template but somehow got a domain name. That market is real and it’s about to get crushed.

But “describe it and build it” hits a hard wall the moment your domain has all four of these:

• Money that moves and has to reconcile to the cent.
• Availability that can’t double-book without somebody getting refunded and angry.
• State that has to survive refunds, no-shows, partial cancellations, deposits, gift cards, comps, and reissues.
• Auditability — you need to explain to a regulator, a customer, or yourself in six months why a specific charge happened.

A booking system has all four. So does payroll, insurance, healthcare scheduling, ticketing, freight, anything HIPAA-adjacent, anything that touches a brokerage. These verticals are where the “AI just builds it” demo hits glass.

The five rules

Here’s what’s actually in Freebo’s CLAUDE.md — the rules every agent that touches the codebase has to follow:

Each of these is a thing I’ve watched a model break.

Money as floats. A model that writes price * 0.085 for tax produces $12.34999999999 when stored as a float. Multiply that across ten thousand bookings and your books are off by hundreds of dollars by Tuesday, and you can’t tell whether the gap is a real reconciliation problem or just floating-point drift. So Freebo stores everything in integer cents. Always. The model isn’t allowed to pick a representation.

// Wrong (what an unconstrained model writes):
const total = subtotal * 1.085;

// Right (what the codebase enforces):
const taxCents = Math.round((subtotalCents * 85) / 1000);
const totalCents = subtotalCents + taxCents;

Mutating a quote when the price changes. A model that “edits” the quote inline loses the audit trail. The customer says “I paid X.” You can’t prove what they were quoted three weeks ago. So quotes are immutable in Freebo — every price change is a new quote version that points back to the previous one. The customer’s receipt is a snapshot, not a live view.

Bypassing the ledger to “just fix the balance directly.” This one looks innocent. The balance is off by a dollar. The model proposes a quick UPDATE to fix it. That UPDATE creates a transaction that doesn’t appear in any report. Every financial operation in Freebo goes through a ledger event pipeline — double-entry, append-only, replayable. The model can write the event. It can’t touch the balance.

Dropping WHERE location_id = from a query. Every row in Freebo’s schema belongs to a location_id — the multi-tenant boundary that keeps operator A’s bookings out of operator B’s dashboard. One missed predicate and a model has just leaked customer data across tenants. So the rule is enforced at the access layer, not the query layer. The model can’t write a raw query that selects from a tenant-scoped table without going through the scoped client.

Overbooking guards. A model that writes a “create booking” endpoint without a transactional lock will let two customers book the same 6 AM slot on the same boat. Both get a confirmation email. One of them shows up to a captain who has no idea why two strangers are arguing on his dock. So availability transitions are guarded — locked, checked, written, released — and the model isn’t allowed to skip the lock.

None of those bugs are catastrophic in a TODO app. All of them are unrecoverable in a system that holds money for someone else’s customers.

Where the line actually is

This is the part nobody talks about in the AI-builds-apps demos. The general-purpose builder doesn’t know your invariants. It can guess at them — and sometimes the guess is fine. But “sometimes fine” isn’t a safety property when the wrong guess is a refund disaster that ends with you on a phone call to a charter captain explaining why his deposit math is wrong.

The next leap isn’t “the AI builds anything”

It’s “the AI composes proven primitives within domain-specific guardrails.”

The hard part of any serious vertical SaaS isn’t the UI. It’s the rules underneath. Once those rules are encoded in tested production code — and once you’ve absorbed every edge case from real operators yelling at you on Slack at 7 AM — you can layer an AI on top that configures and composes them safely. The model never invents the money math. It picks which proven money math applies, fills in the parameters, and stops.

I’ve got some half-formed thoughts about what that layer looks like on top of Freebo. Operator describes the business in plain language, system assembles a configured reservation system from the primitives, ledger and quote engine sit underneath untouched. I’ll write about it when it’s less half-formed. The short version is: the AI’s job is configuration, not generation, and the surface area it’s allowed to touch is exactly as small as the surface area I’m willing to be wrong about.

So no, Replit isn’t eating Freebo

It’s eating the fifty generic SaaS knockoffs that should have been a Notion template. Good — most of them weren’t earning their existence anyway.

The verticals where being wrong by 1% loses real money — booking, payroll, ticketing, freight, healthcare scheduling, insurance, anything regulated — are going to belong to whoever encoded the invariants first. Not whoever ships the prettiest builder.

If you’re building anything in one of those verticals, the question to ask isn’t “can I beat the AI builders to the next feature.” It’s: what are the five rules my software gets right that an AI couldn’t guess?

Write those down. They’re your moat. Mine fits on the back of a napkin and it took six months in production to learn what belonged on it.

That’s basically the whole strategy.