How MechIQ was built

An independent garage is a fast, physical business running on paper and memory. A car comes in at 08:00 with a vague complaint. A technician finds two other things wrong with it by 10:00. Someone rings the owner, who approves one of them and not the other. Parts get ordered from three different factors. The car goes out at 17:00, and somewhere in all of that an invoice has to appear that matches what was agreed and what was done.

Most of that lives in someone's head until it doesn't. A serious amount of the day goes on work that earns nothing: the same registration typed into three different places, an approval chased twice because nobody wrote it down the first time, an evening spent working out whether last week made money. That's time the garage isn't being paid for, and margin that rounds down on the way through.

Two things cost more than the rest. Quoting is the big one: pricing a job properly means working out what the job involves, what the parts cost and what to charge for the labour, usually while somebody waits on the phone. The other is that a technician who needs the work plan, or the manufacturer's data for the car in front of them, has to put their tools down and walk to a shared computer to find it.

Those are the two MechIQ went after first. The quote is drafted from the customer's description and the vehicle, priced against real parts and manufacturer times, and the front desk edits it rather than building it from scratch. The work plan and the manufacturer's data sit on a tablet in the technician's hand, at the car.

Software is supposed to fix this, and garages do pay for it. The problem is what it's built on. The main systems in this market are layers on top of foundations that are decades old, and it shows where it always shows: the data model fights you, anything new gets bolted to the side. AI turns up as a badge on a screen that was designed when the answer to everything was another dropdown. You can't retrofit your way out of a foundation.

That's the gap Dave saw. He'd spent his working life in and around garages, he knew exactly where the money and the time go, and he was certain the thing that would fix it didn't exist yet.

So he came to me for advice. He wanted to know how you get funding to hire a team of engineers and build it, which is a reasonable question with a well-worn answer: raise a seed round, hire four or five people, spend eighteen months and most of the money finding out whether the idea was right.

I went away and thought about it, and came back with something else. AI coding tools had got good enough, over the previous year, that I thought I could build it myself. Not a prototype. The actual thing. So instead of helping him raise money to hire engineers, I suggested we go into partnership.

That was six months ago. It's live, it's in garages, and no money was raised.

Building from nothing is usually the stupid option. Here it was the whole point. Starting now means you can ensure AI is in the middle of the product instead of beside it, and design the data model around how a workshop really runs instead of around what the previous system could store.

I knew systems. I knew nothing about garages.

What I brought was a way of building things that stay up and stay safe. Isolation that holds even when the code is wrong. Failures that are loud rather than silent. A system that can go from one garage to a thousand without being rebuilt to get there. Those principles went in before any of the features did, which is why most of this post is about foundations.

The garage half I had none of, and that's not false modesty. When we started I couldn't have told you what a vehicle health check was, why a garage would ever hold a part on a shelf rather than order it when needed, or how a customer approving two jobs out of four on a phone call turns into an invoice that balances.

Dave has spent his working life in and around garages, and he's the reason this is a product rather than my idea of one. He doesn't send me feature requests. He runs real jobs through it, in a real workshop, and tells me where it falls apart.

Most of what's distinctive about how MechIQ works came out of that. Where approval sits. What a technician is allowed to do and what has to go through the front desk. When a part gets ordered and when it waits. Those are judgement calls about how a workshop runs, and I'd have got most of them wrong on my own, confidently.

Without him I'd have built something that worked and that no garage wanted. I'm fairly sure that's the more common failure.

What I built first

Before there was much of a product, there was scaffolding: the processes, tooling and checks everything else would be built on.

In the first few weeks I wrote a suite of static checks that run on every build and fail it: every endpoint has a role guard, every model that holds a garage's data is tenant-scoped, every database migration that creates such a table carries a row-level security policy. Structured logging with a correlation ID on every request went in at the same time, along with a check in the build that refuses any dependency published in the last 24 hours, so a freshly poisoned package can't get in while I'm asleep.

None of that made a single screen work. I built it first because I've spent twenty-five years watching what happens to systems where nobody did.

The one I care most about is tenant isolation. Every garage shares one database, which is normal, and is also the thing most likely to end the company. So the application isn't trusted to remember: isolation is enforced underneath it by Postgres, and the role the app connects as isn't permitted to bypass it. A forgotten filter returns nothing at all rather than somebody else's data. The mechanics of that are worth a post of their own.

Evenings, weekends, and what that forces

This has been built in evenings and at weekends. That constraint shaped more of the engineering than the technology choices did.

When you might not look at the system again until Thursday, you can't be the thing that notices something going wrong. So it has to either hold on its own or shout loudly enough to reach a phone. Every background job has a dead-man alarm. When an AI call fails and the system falls back to a dumber answer, that raises an alert instead of carrying on in silence.

Deployment follows the same logic. A change builds once, proves itself on a staging environment, and the exact image that passed is the one promoted to production. Nothing is rebuilt in between, because the alternative is finding out on a Saturday that a rebuild pulled a different library version.

The database runs across two availability zones with automatic failover, as does the cache, backed up daily with a week of retention. Unremarkable if you've run production systems. Missing from a lot of small software.

The week I wrote the manual

The most useful thing I've done recently wasn't a feature. I wrote the help centre, 137 articles covering every screen, then went back and checked every claim in it against the code.

About a third of what came back wasn't a documentation error. Six settings a garage could happily change that changed nothing, because no code ever read them. A customer survey that got prepared and never sent. A button that had been returning a server error for a month, because a function had been deleted while three callers still used it somewhere nothing checks until a user clicks.

Here's the thing: none of that breaks. A setting nothing reads doesn't throw an error. A draft nobody sends doesn't fail. It all sails through every test I have. Having to write down in plain English exactly what the software does for a customer turned out to be a sharper test than any suite I own, which was not the lesson I expected from a week of writing documentation.

Where it is

Live on AWS, with garages running real jobs and real invoices through it, and the full migration of our first garage happening this month. Native apps for technicians are on both the App Store and Google Play, and there have been 360 database migrations to get here.

The number I'd point at, though, is the tests. There are 4,428 of them, and every one runs before code reaches a garage.

That's a lot for a solo build, and it isn't thoroughness for its own sake. It's the only way one person changes something on a Tuesday evening and knows by Tuesday night that invoicing still works. The tests aren't overhead on the work, they're what makes the pace possible at all. (If you want the breakdown and what each layer is for, it's in the architecture post.)

It connects to what a garage already pays for instead of asking them to abandon it: manufacturer technical data, parts catalogues, Sage, Xero and QuickBooks.

What I'd want to know, if I were you

Whether one engineer can be trusted with running your garage.

My answer is that headcount was never what made software reliable. What makes it reliable is assuming you'll get things wrong, and building so the damage is contained when you do. Let the database enforce isolation instead of relying on your own discipline. Ship the thing you tested, not a near-copy. Make failures loud. Keep going back to check whether what you believe about the system is still true, because a surprising amount of it stops being true without anything breaking.

That's twenty-five years of engineering leadership on systems where downtime isn't an option, and it's the one thing I brought to this that Dave couldn't. Active/active data centres, where an entire site could fail without customers noticing. Payment infrastructure held to audit and regulatory standards, where the evidence matters as much as the uptime. Availability for consumer services with more than a hundred million users and cloud spend in the tens of millions. And building an incident management function for a global customer support platform.

Incident management has been present throughout my career. Designing how a company responds when something breaks teaches you more about building software than designing how it behaves when everything's fine.

MechIQ is a far smaller system than anything I've run before. Our garages trust us to run their business, which raises the bar rather than lowering it. A garage that can't invoice on a Friday afternoon doesn't care how cheap the software was.

AI made this possible. It wrote a lot of the code and it made me faster than I thought I could be. It made none of the decisions above, and it's perfectly capable of producing something that looks right and isn't. Knowing the difference is the job, and it's the half that doesn't come in a subscription.