Garage management system

Where it started

This one arrived from the customer's side of the counter, and it did not start with a garage that had no software. It started with a garage that had already been sold some.

What they had was poorly built, did not do what it promised, and carried a bill that kept arriving anyway. Software that does not work is worse than no software, because the work still has to happen: the real operation had quietly fallen back to paper job cards, a whiteboard and a stack of WhatsApp groups, while the system they were paying for sat unused.

What made it worth building was not that the problem existed. It was why every available answer had failed them.

Why it stayed unsolved

An independent garage sits in a gap the software market has never served well. It is offered three things, and all three fail it differently.

Products sold to small businesses precisely because they are small. Thinly built, oversold, priced as though the buyer will not compare, and supported as though they will not complain. This is what they had.

Serious systems built for companies ten times the size. Capable, and overkill: priced for a finance department, configured over months, and demanding more administration than a workshop of that size can carry.

Or four or five separate tools, one for invoicing, one for stock, one for staff, stitched together by whoever is least busy. Each is defensible alone. Together they are a systems administration job nobody at a garage was hired to do.

What they wanted was neither ambitious nor unusual: one lean thing, that works, that a small team can manage without hiring anyone to manage it. That is the gap, and it is the same gap at every independent garage, which is what makes it worth building once and running for many.

How we approached it

The three weeks in the middle are the part most studios skip. We already had a customer who wanted it built. What we did not have was evidence that anyone else did. Spending three weeks establishing whether a market existed, before writing production code, is the difference between a product and an expensive favour.

Ten weeks in total, from the first morning in the workshop to software people were using.

What we built

One place where a job lives from the moment it is booked to the moment it is paid for.

• Job cards, from intake through to invoice
• Inventory and parts, so stock is a number rather than a guess
• Technicians and payroll
• Accounts, and profitability calculated per job rather than per month

The last is the point. Job-level profitability is what a stack of paper can never give you, and it is what turns a workshop from a business that is busy into a business that knows which work is worth taking.

Some things were deferred rather than dropped. E-invoicing and other worthwhile additions were phased for later, because the first release had to replace what they were actually using, not out-feature software nobody had adopted yet.

What we chose not to build

CRM. It was the obvious adjacent feature and we ruled it out on purpose.

This is an ERP, and the two disciplines pull in opposite directions. A CRM exists to help you sell more. This exists to help you run better: tighten the process, take cost out, standardise how work is recorded, and put a serious interface in front of a trade that has never been offered one.

Building both would have meant doing neither well, and would have turned a tool the workshop uses every day into a system somebody has to be persuaded to adopt.

What changed

The clearest effect is on where the day goes. Administration that previously consumed hours, chasing job cards, reconciling parts, assembling invoices from whatever survived the process, now happens as a by-product of doing the work. Those hours come back, and they go into the jobs themselves and into the customer relationships and marketing a small garage never has time for.

Two quieter effects matter as much. Information that had been scattered across group chats, paper and a system nobody trusted now sits in one place, which closes an exposure nobody had priced. And because it arrives as a product rather than as infrastructure, the business stopped paying for software it was not using, and avoided the IT spend that owning a system normally drags behind it.

In their words

“We had already paid for software that never really worked, and the invoices kept coming regardless. Everything else was either built for a company ten times our size or meant running four different systems with a team that has no time to run any of them. We wanted one lean thing we could manage ourselves. They spent a week on the floor with us first, which is why what we got actually fits how we work.”