A colleague at the charity I volunteer with was looking at their new website. I'm building the new website for them; she's been one of the people testing it. She was looking at the page that lists when the rooms are available, and she said:
"Wouldn't it be great if they could click on an available time and send a reservation?"
It was an offhand remark. Not a feature request, not a brief, not anything she expected an answer to.
I want to sit with that for a moment, because it's the bit that matters.
What didn't happen
At a charity our size, you don't raise feature requests. You already know the answer. The budget for things like this has always been zero — not £5,000, not £500, not £50. So nobody raises them. The thought wouldn't it be great if we could… runs through someone's head, lands as a faint observation, and dissolves before it becomes a sentence anyone says out loud, let alone writes down.
Over years, this stops being a cost problem and becomes a language problem. The asking itself disappears. People stop articulating the improvements that would help their work, because they've learned there's no list those requests get added to. The wouldn't-it-be-great-ifs sit invisibly in the heads of the people doing the work, unspoken, unmeasured, uncountable.
That's the deeper consequence of a structural zero budget. It's not just that the work doesn't get done. It's that the work doesn't get imagined. After enough years, you stop noticing the things that would help, because noticing them is its own small grief.
So the fact that my colleague said anything at all is worth noting. She wasn't expecting me to do anything about it. She was thinking out loud, at a moment when she happened to be testing a website that a volunteer had been quietly building with AI. That's the only reason the sentence existed.
What did happen
I went home and opened Claude Code.
Twenty-four hours later, 80% of it was working. The plugin takes the room-bookings API feed the website was already showing, turns it into a clickable interface, and posts the reservation back through the API. From the user's perspective, the listing went from passive (here's when it's free) to active (here's when it's free and here's how to book it).
I want to be honest about what's not done yet, because honesty matters more than completion claims. The remaining 20% — edge cases, confirmation flows, a couple of UI polish items — is still in progress. It'll ship with the rest of the site in the coming weeks.
What I'm not going to claim is that AI built this on its own. It didn't. The honest version is more interesting than that, and it has implications.
What actually happened
I'm not a developer. I never have been.
I'm a senior business analyst with three decades of data and systems work behind me. The first chunk of that career was fourteen years at Nelsons in Wimbledon — a UK natural health care products manufacturer working under a pharmaceutical manufacturing licence. Six years as IT Manager rebuilding their infrastructure and migrating their operating divisions onto Sage Line 500, then eight years as Business Applications Manager running their integrated ERP, data warehousing, demand planning, financial planning, and CRM landscape. I led the data migration to SAP in the closing years.
Across all of that, my actual craft has always been the same: understanding data structures, understanding what users actually need (which is almost never what they first ask for), and making the systems and the people meet in the middle.
That's the craft that built the room-bookings plugin.
The intelligence in this build was me knowing the data. I'd built the page that displayed the booking data. I understood how the API feed was structured, what each field meant, how the reservation flow on the back end actually worked. When my colleague made her remark, I could translate it into a working brief in about thirty seconds, because I'd done that translation thousands of times across thirty years.
The assistant was Claude Code. I directed. It executed. I reviewed. I refined. I tested. I broke things and fixed them. I took responsibility for what shipped.
This is the IA Framework operating in the hardest domain there is. Custom software. Real users. Wrong output isn't a typo — it's a broken reservation, a double-booked room, a user who never comes back. If the framework's five principles — You Lead, It Follows; Brief It Like a Professional; Work in Loops, Not Lines; Trust But Verify; Expand What's Possible — work in this domain, they work everywhere.
The implication for SMEs and charities
Here's what I think most SME owners and charity leaders haven't fully registered yet, because the AI conversation has been so dominated by the wrong stories.
A whole class of work has just become accessible. Not cheaper. Not faster in the sense of the same agency quotes in less time. Accessible — to organisations whose budget for it was always, structurally, zero.
Small bespoke integrations. Quiet automations. Custom dashboards. The internal tools the team keeps not-asking-for. The wouldn't-it-be-great-ifs that never even reach a meeting agenda because everyone has already done the calculation in their head and concluded there's no point.
What unlocks that work isn't a developer. Developers were always available; the problem was never supply. The problem was that the route from a colleague's offhand remark to working software involved so many handoffs, so much scoping, so much vendor management, so much money, that the maths never worked at SME and charity scale. So the remarks stopped getting made.
That route just collapsed.
What replaces it is one person. Someone who knows the data, can read a colleague's observation and turn it into a brief, will verify what the assistant builds, and will take responsibility for what ships. In a sense, that person has always been the missing ingredient — the business analyst with technical depth, working close enough to the operation to translate need into structure. Until very recently, that person couldn't ship code; they could only specify it for someone else to build. Now they can ship.
That's what Mv32 is built around.
Why discipline still matters
I want to head off the obvious objection, because I share it.
There's a version of this story that says "anyone can now build software with AI" and that's the version I think is dangerous. AI is confident even when it's wrong. It produces output that looks plausible and runs cleanly and then fails the first time a real user does something the developer didn't anticipate. The internet is filling up with software written by people who shipped what the assistant gave them and never looked twice.
That's not what good practice looks like.
Earlier in my career, I led the data migration to SAP at Nelsons. IBM had forecast a 10% error rate. Our go-live came in at less than 0.1% error per million rows — a hundred times better than the professional forecast. That's not a humblebrag. It's the result of the same discipline that produces good software from AI: knowing your data, briefing precisely, working in loops, verifying everything, and holding accountability for what ships.
Without that discipline, AI produces confident-looking software that quietly breaks. With it, AI lets a senior BA ship work that would have needed a development team a year ago.
The discipline isn't optional. It's the whole game.
What this means if you're reading this
If you're running a small charity, a small business, a community organisation: there is a list somewhere — not on paper, not on a board agenda, but in the back of someone's head — of wouldn't-it-be-great-ifs. Things that would help the work. Things nobody's bothered to articulate properly because everyone already knows there's no budget.
That list just became reachable.
You don't need a six-figure digital transformation budget. You don't need a dev team. You need someone who can listen to a colleague's offhand remark, recognise the tractable problem inside it, know enough about the data and the system to brief the work properly, and take responsibility for what gets built.
You also need to give people permission to start saying the things they stopped saying. That part is on you, not on me. The technology has changed; the culture that grew up around the technology hasn't caught up yet. People have to be told it's worth raising the small ideas again, because the small ideas are suddenly small enough to do.
That's the work I'm now doing through Mv32. Quietly, at SME and charity scale, with the discipline thirty-five years of systems work has built up, and the new capability AI has just made available.
A question for you
I'd love to hear what's on your list.
What's the wouldn't-it-be-great-if your team has stopped articulating because you all know there's no budget?
Drop it in the comments. No pitch, no obligation. I read every reply, and even if nothing comes of it commercially, the conversation itself is worth having. Some of these things are easier than you think.
If any of this resonates, let's grab a coffee.