Why I Don't Let a Roadmap Decide What Gets Built Next

<p>I think roadmaps are a bit of a lie we tell ourselves to feel in control. Not a malicious lie — a useful one, the kind that makes a messy, reactive process look like a plan. But the longer I run Intelli AI, the more I think the roadmap should be treated as a hypothesis, not a commitment.</p><p>Here's my reasoning. A roadmap gets written at a point in time, based on what you know then. For AIREP, that might be "next quarter we productize invoicing templates" or "next sprint we generalize the procurement module." It sounds sensible on the day you write it. But a week later a real constraint shows up — a tenant's data model doesn't fit cleanly, or Gripswich OS surfaces an edge case that AIREP doesn't have, or an agent working on Nova finds a refactor that unblocks three other things. None of that was visible when the roadmap was written, because none of it could have been.</p><p>My view is that for a small, bootstrapped operation, the roadmap's job isn't to be followed — it's to be a record of intent that you're allowed to override the moment reality disagrees with it. The failure mode I want to avoid is sticking to a plan because it's the plan, not because it's still the right call. That's a corporate disease, and it's easy to catch even when you're a team of one plus some AI agents.</p><p>This matters more with AI in the loop, not less. When agents can review, refactor, and sometimes suggest their own next steps, you get a constant stream of candidate priorities that didn't exist when you last sat down and planned. If I force every one of those signals through a quarterly roadmap process, I'm throwing away the main advantage of having agents working on the codebase in the first place — their ability to surface what actually needs attention right now, not what I guessed would need attention a month ago.</p><p>The counter-argument is obvious: without a roadmap, you drift. You chase whatever's loudest today and never ship anything coherent. I don't think that's wrong, exactly — it's why I still keep a roadmap at all, for AIREP, for Gripswich OS, for Nova. But I treat it as a prior, not a constraint. It tells me where I expected to be. It doesn't get a vote on where I actually go when the ground shifts.</p><p>The place I apply this most deliberately is the boundary between AIREP as a productized SaaS and Gripswich OS as a bespoke platform. A roadmap written for one will almost always tempt you to bend the other to match it, because consistency feels like progress. I'd rather have two systems that stay honest about what they actually need than one unified plan that quietly drags a bespoke platform toward multi-tenant assumptions it was never designed for, or drags AIREP toward one customer's quirks. The roadmap doesn't get to merge them just because it would look tidier on a slide.</p><p>Where I land is this: plans are for direction, not obedience. I want enough of a roadmap to know roughly where I'm heading with AIREP, with the gym platform, with Nova's self-improvement loop — and I want to be able to throw any part of it out the moment something closer to the ground tells me it's wrong. The discipline isn't in sticking to the plan. The discipline is in noticing, honestly and quickly, when the plan has stopped matching reality, and not pretending otherwise just because it's already written down.</p>