Why Gripswich OS and AIREP Will Never Merge Into One Product

<p>I run two systems that look, on paper, like they should eventually become one thing. Gripswich OS runs GRIPswich Bouldering, a single gym in Ipswich. AIREP is meant to be a multi-tenant ERP that any small Australian business can sign up for. Both are software for operating a business. Both lean on AI as the core differentiator rather than a bolt-on. It would be tempting to look at that overlap and think: why not fold Gripswich OS into AIREP as a vertical, or build Gripswich features as a module?</p><p>My answer, after sitting with both systems for a while, is that I don't think that's the right move, and it's worth explaining why, because the reasoning applies to more than just these two products.</p><p>Gripswich OS exists to serve one business exactly as that business operates. Every decision I make about it can be made in reference to a real, specific set of problems GRIPswich actually has — how classes get booked, how memberships get tracked, what the front desk needs to see in two seconds. There's no abstraction tax. If something's awkward, I change it, and there's no second tenant whose workflow I might break.</p><p>AIREP is the opposite kind of project. It has to be generically right, not specifically right. The moment I start shaping its schema or its workflows around one business's quirks, I've made it worse for every other business that isn't that one. A productized system has to resist the pull toward bespoke convenience, because that convenience for one tenant is friction for all the others.</p><p>Those are two different design disciplines, and I don't think a single codebase can hold both honestly. I've written before about why multi-tenant and bespoke work can't share a codebase, and the gym platform versus the ERP is the clearest version of that tension I have in front of me. If I tried to merge them, I'd end up with a gym module inside AIREP that's either too generic to actually help a gym, or specific enough that it drags the rest of the product toward one business's assumptions.</p><p>There's also a practical reason to keep them separate: they're at different points in their life. Gripswich OS has been running the gym since August. It's proven in exactly one place, and that's fine — that was the point. AIREP is still working toward its first paying licence, which means every architectural choice there has to be evaluated against "would this work for a business I haven't met yet." Those two questions — does this work for the business I know, versus does this work for a business I don't — pull in different directions, and conflating them would slow down whichever one I was actually trying to ship.</p><p>None of this means the two projects don't talk to each other. Gripswich OS is where I get to see what a real small operator actually needs from day-to-day software, unfiltered by the need to generalise it. That's useful input into AIREP's design, the same way designing for a specific first customer sharpens a generic product rather than diluting it. But input isn't the same as shared code. I can learn from running a gym's backend without GRIPswich's billing quirks leaking into a schema meant to serve a driving school or an engineering firm.</p><p>The temptation to unify systems that look similar is a trap I think a lot of small software businesses fall into, usually in the name of efficiency. Fewer codebases, less to maintain, reuse what you've already built. I get the appeal, especially bootstrapped and without the headcount to maintain parallel systems forever. But efficiency that costs you correctness in either direction isn't efficiency, it's just deferred rework. I'd rather run two systems that are each right for what they do than one system that's a compromise for both.</p>