Why I Keep AIREP and Gripswich OS on Different Databases on Purpose

<p>AIREP is built on a database-per-tenant model. Every business that runs on it gets its own isolated database, provisioned the same way, migrated the same way, backed up the same way. It's the right architecture for a product that's supposed to scale to a lot of small businesses that don't know each other exist and shouldn't have to care about each other's data.</p><p>Gripswich OS doesn't work that way, because it isn't trying to be a product in that sense. It's a platform built for one gym, GRIPswich Bouldering, and it has been live since August. There's no tenant boundary to enforce because there's only one tenant. Building it with the same isolation machinery as AIREP would mean carrying complexity that has no job to do.</p><p>It would be tempting to say: just run Gripswich OS as a tenant inside AIREP. One codebase, one set of migrations, one place to fix bugs. I don't do that, and the reason comes down to what each system is actually for.</p><p>AIREP's job is to be generic enough that a business I've never met can configure it for quoting, procurement, invoicing and inventory without me writing custom code for them. Every feature has to earn its place by being useful across different kinds of businesses, not just useful once. That constraint is what makes it productizable at all.</p><p>Gripswich OS has no such constraint, and that's its advantage. It can have features that only make sense for a climbing gym — things tied to how a bouldering gym actually runs day to day — without worrying whether they generalise. If I forced it through AIREP's abstraction layer, I'd either have to generalise features that don't need to be generalised, or special-case the one tenant that doesn't fit the mould. Both of those are worse than just keeping it separate.</p><p>The deeper issue is that bespoke and multi-tenant optimise for opposite things. A multi-tenant system is optimised for sameness — the less each tenant's setup diverges from the others, the cheaper it is to support all of them. A bespoke system is optimised for fit — the more precisely it matches one business's actual workflow, the better it is. Trying to get both properties out of one codebase means compromising on both. You end up with a product that's too specific to scale and too generic to delight anyone.</p><p>This isn't a new realisation for me, it's just one I keep re-confirming every time I'm tempted to collapse the two systems into one for the sake of tidiness. Tidiness is not a business requirement. Fit and scalability are, and they point in different directions here.</p><p>What I do carry across is the thinking, not the code. Problems I solve for Gripswich OS — a cleaner way to handle procurement, a pattern for surfacing the right data to the right person at the right time — often clarify what AIREP should offer to businesses in general, even if the implementation can't be shared line for line. And problems that come up productizing AIREP sometimes point me at a feature GRIPswich itself would benefit from. The two projects inform each other even though their codebases will never merge.</p><p>If I ever get to the point where there are multiple gyms wanting something like Gripswich OS, that's a different conversation — at that point it starts looking like a product decision rather than a one-off platform, and it would need its own multi-tenant design built for gyms specifically, not retrofitted onto AIREP's shape. But that's a future problem with its own answer. Right now, two codebases solving two different problems is simpler and more honest than one codebase pretending to solve both.</p>