Why Productizing Something Bespoke Is Harder Than Building It

<p>I've been thinking a lot lately about the gap between building something for one business and building something for many. It sounds like a scaling problem — add multi-tenancy, generalize the config, done. But my view is that's the easy 20%. The hard part is that a bespoke system is allowed to have opinions baked in that only make sense for one business, and a product isn't.</p><p>When you build for a single client, every decision can be informed by exactly how that business operates. You know their quoting workflow, their procurement quirks, how they want invoices to look. You don't need to ask whether the pattern generalizes, because it doesn't have to. It just has to be right for them.</p><p>The moment you try to turn that into something another business can pick up and use, every one of those decisions becomes a question. Is this specific to them, or is it actually how most small businesses in this category work? You don't find out by guessing — you find out by having more than one real tenant with real, different habits, and watching where your assumptions break.</p><p>This is part of why I think the database-per-tenant approach matters so much for AIREP. It's not just an isolation or security decision, though it's that too. It's an admission that I don't yet know which parts of the system are universal and which parts are one client's preferences wearing a general-purpose costume. Keeping tenants cleanly separated means I can let each one diverge where it needs to without that divergence leaking into the core product and quietly becoming "how AIREP works" for everyone.</p><p>The same tension shows up with Gripswich OS. It was built to run one specific gym, with real operational detail baked in — the way a climbing gym actually runs day to day doesn't look like the way a trades business runs, which doesn't look like how a driving school runs. Each of those shaped my thinking about AIREP as a general ERP, but none of them are the general case. Part of the discipline is noticing when something I built because it made sense for this gym is actually just a sensible default, versus something that only makes sense for this gym.</p><p>I think the honest version of productization isn't "generalize everything up front." It's closer to: build for the one real case you have, because abstract software built with no real constraints tends to be wrong in ways you can't see yet. Then, as you get a second and third real case, go back and find the seams — the places where your first build assumed something that wasn't actually universal. Pull those apart carefully. Leave the rest alone.</p><p>It's slower than designing a "proper" multi-tenant platform from day one. But I'd rather have a system that's demonstrably correct for the businesses actually using it than one that's theoretically correct for a category of business I've imagined. The theoretical version always has a seam somewhere that nobody's tested, because nobody's real operations ever quite match the model you built in your head.</p><p>This is also, I think, where a lot of SaaS products in the small-business space go wrong — they're built to the idealized shape of "a small business like yours," and then every real customer spends their first few months fighting the gap between that idealization and how they actually work. My bet is that honest productization means staying closer to the real, messy cases for longer before you let yourself believe you've found the general pattern. It's less satisfying than declaring victory early. But it's the only way I know of to end up with something that actually fits.</p>