Why I Write Down the Boring Parts of the Business Too

<p>If you look at what I write about publicly, it's mostly AIREP's architecture, Nova's agent design, or Gripswich OS's build decisions. The interesting stuff, basically. What I don't talk about much is the unglamorous layer underneath all of it: quoting, procurement, invoicing, inventory. The operational plumbing that has nothing to do with AI and everything to do with whether a small business actually functions day to day.</p><p>I think that's a mistake, and not just for the blog. It's a mistake in how a lot of software gets built generally. Engineers — myself included — gravitate toward the parts of a system that are intellectually satisfying to design. Multi-tenant database isolation is fun to think about. A self-improving agent loop is fun to think about. Writing a quoting module that handles GST correctly and doesn't let a quote silently expire is not fun to think about. But for the actual small business owner using AIREP, the boring module is the one they touch fifty times a day, and the exciting module is the one they might never notice is there.</p><p>This is part of why I keep coming back to the idea that small operators deserve software shaped like their business, not software shaped like an engineer's idea of what their business should look like. A gym, an engineering firm, a driving school — these businesses run on invoicing cadences and procurement habits that are specific and unglamorous and completely non-negotiable. If the AI-native layer on top of AIREP is brilliant but the invoicing is wrong, none of it matters. The business owner doesn't care that the quoting engine is backed by a well-designed tenant-isolated database. They care that the quote went out correctly and the client paid it.</p><p>I've started treating the boring operational features as the actual product, and the AI layer as the thing that makes the boring product better rather than the thing that justifies the boring product's existence. That's a subtle but real shift in how I prioritise what gets built next. It means a procurement workflow that saves someone ten minutes a week is not a lesser feature than an agent that reviews code. It might be the more important one, because it's the feature that makes someone trust the system enough to put their whole business inside it.</p><p>There's a trap in AI-first thinking where you start believing the intelligence is the product. I don't think that's right, at least not for something like AIREP. The intelligence is leverage on top of operations that have to be solid regardless. You can't out-AI a business that doesn't trust its own invoices. The boring 80% has to work before the clever 20% means anything.</p><p>This is also why I think documentation and internal notes about the plumbing matter as much as architecture diagrams. When I'm deciding what AIREP needs next, the useful question isn't "what would be an interesting system to build" — it's "what does a real procurement workflow at a small business actually look like, and where does it currently break." That's a less exciting question to sit with, but it's the one that gets you to a product someone will actually pay for and keep using.</p><p>So this is me making a deliberate note to myself, publicly: the unglamorous layer isn't a tax you pay to get to the interesting AI work. It's the thing the AI work is in service of. If I ever catch myself spending more time thinking about agent orchestration than about whether a quote correctly rolls into an invoice, that's a sign I've got the priorities backwards.</p>