Why I Don't Let One Codebase Tell Me What 'Done' Means

<p>I work across a few different systems in a given week — AIREP, Gripswich OS, Nova, this site, client builds. They're all mine, in the sense that I wrote or shaped most of the code, but they're not the same kind of thing. AIREP is trying to become a product. Gripswich OS is a bespoke platform doing a specific job for a specific gym. Nova is an assistant that runs partly in the cloud and partly on a box at home. Each of those has a different definition of 'done,' and I think the biggest trap in solo software work is importing the definition from one project into another without noticing.</p><p>On a productized system like AIREP, done means something close to: works correctly for a tenant I've never met, under conditions I didn't predict, without me in the loop. That's a high bar, and it should feel uncomfortable, because the whole point of productizing is that you're writing for strangers. On Gripswich OS, done means something much narrower: it does what this gym needs, the way this gym operates, and I can change it quickly if that changes. That's not a lower bar — it's a different one. Bespoke software optimized for generality is usually worse bespoke software, not better.</p><p>I've caught myself, more than once, judging one project by the other's standard. Looking at Gripswich OS and thinking 'this isn't abstracted enough' — as if abstraction were a virtue in itself rather than a tool for a specific problem, namely serving tenants you haven't met yet. Or looking at AIREP and thinking 'this is taking forever to get right' — forgetting that the reason it's slower is that it has to be right for cases I can't currently enumerate. Neither thought is useful. They're both just the wrong ruler applied to the wrong plank.</p><p>The same thing shows up with Nova. The cloud tier and the home-box tier aren't the same software held to the same bar — they're solving different problems under different constraints. The cloud tier has to be available and consistent. The home-box tier is about keeping certain things local and under my control, even if that means it's slower or less polished in places. If I measured the home-box tier purely on uptime or polish, I'd conclude it's failing at something it was never trying to do.</p><p>I think this matters more than it sounds like it should, because the instinct to unify is strong, especially when you're the only one maintaining everything. One codebase, one set of conventions, one definition of quality — it's appealing because it's less to hold in your head. But I've come to think that instinct is often wrong at the project level even when it's right at the code level. Share patterns, share lessons, share infrastructure where it actually overlaps. Don't share the definition of success, because the definition of success is downstream of what the thing is actually for.</p><p>Where this gets practically useful is in deciding what to fix first. If I'm context-switching between AIREP and Gripswich OS in the same day, the question isn't 'which one needs more polish.' It's 'what does done mean for this one, right now, and how far is it from that.' A rough edge in Gripswich OS that would be disqualifying in a multi-tenant product might be completely fine, because the gym doesn't care and I can patch it in ten minutes if it ever does. A shortcut in AIREP that would be fine in a one-off build is a liability, because someday a tenant I've never spoken to is going to hit it.</p><p>None of this is a sophisticated insight. It's closer to just not lying to myself about what each system is for. But it's the kind of thing that's easy to drift away from when you're moving fast across projects, and worth saying out loud so I keep catching myself.</p>