What I Built To Run This Business

I run a software business, so when something about running it annoyed me, my first instinct was to write something. Over a few months that turned into a set of tools that now handle most of the administration here. This is what they are, what each one actually does, and what I would say to anyone thinking of doing the same, which is not straightforwardly "go ahead".

Why I started

The specific thing that pushed me was not a grand plan. It was that a single client existed as five separate records in five different systems, spelled slightly differently in each, with nothing tying them together. The customer relationship tool had one version. The project tracker had another. My notes had a third. The invoice log had a fourth, and it was a table in a text file that I searched by hand to work out what the next invoice number should be.

None of that is unusual for a business at this size. It is what happens when you adopt tools one at a time as you need them, which is the sensible way to do it. The problem is not any individual tool. It is that the joins between them are held together by you remembering things.

The small tools came first

The first few were narrow, and each one solved exactly one irritation.

• Hours. A timer with a rate attached, so billable time is recorded when it happens rather than reconstructed from memory at the end of the month.
• Mileage. Business journeys logged against the approved rates, so a mileage claim is a report rather than an afternoon.
• Cash flow. A month-by-month forecast of what is coming in and going out, with contracted money kept strictly separate from money that is merely likely.
• Contacts. A local address book with the history of dealing with each person attached to their record.

They all worked. Each one was better than the spreadsheet or the note it replaced. And collectively they made the original problem slightly worse, because now the same client existed in more places than before.

Then one thing that joined them up

So the next build was the one that mattered: a single application that absorbed those four and added the things that were still living in text files. Invoicing, quotes, purchase orders, subscriptions, expenses, contracts, documents, notes, projects and enquiries. One record per client, one identifier, everything hanging off it.

The practical difference is not that any individual job got faster. It is that questions I could not previously answer without opening four things now have an answer. What is this client worth. What is outstanding. What did we agree and when. What have I not invoiced yet.

That build also retired two paid services I had been using: a customer relationship tool and a project tracker. Neither was a bad product. They were built for teams that hand work between people, and there is nobody here to hand anything to.

The tools for particular jobs

Alongside that, a handful of things that do one specific job properly.

• Fleet. Vehicles, drivers, insurance, inspections and the dates that matter. It exists to answer one question: what is overdue or about to be. It treats a blank date as a problem rather than as an absence of a problem, because a missing inspection date is not the same as an inspection that is in date.
• Risk assessments and method statements. Builds the safety paperwork trade contractors need per job, starting from a library and then being rewritten for the actual site. Approval is a named person signing to say it is suitable for that job, and that stays a human decision.
• Keys. A store for the credentials that services need, which knows which project expects which variable and where each one gets written. It cannot show me a value from outside the application, which is the point.
• Flow. Draws process diagrams from a description, so a workflow can be written down and looked at rather than explained again each time.
• Mail. Reads the business mailbox, so correspondence sits alongside the client record it belongs to.
• Print layout. Lays out many small designs onto a fixed-width print film at the shortest length that fits, which saves material on every run.

What this actually cost

Time, mostly, and more of it than any individual tool was worth on its own. I would not have built any one of these to save the hours it saves. What made it worth doing is that they share a spine, so each new one is cheaper than the last, and that I learn a problem properly by building it, which turns out to matter when a customer asks for something similar.

There is also a real ongoing cost that does not show up at the start. Software you wrote is software you maintain. Nobody else is going to fix it, and every one of these is now something I am responsible for indefinitely. That is a genuine liability and I would be misleading you if I left it out.

Would I tell you to do this

Mostly no, and I want to be straight about that rather than sell the approach.

If you are running a business that is not a software business, buying the tool is almost always the right call. The subscription is cheaper than your time, somebody else handles the maintenance, and the thing you are good at is not building administration software. The businesses I work with are usually better served by a well-chosen off-the-shelf tool than by anything bespoke, and I say so when they ask.

The case for building is narrower than it looks. It holds when the tool is the product, when the work of building it teaches you something you need anyway, or when what you need genuinely does not exist in a shape that fits. It does not hold because the subscription feels expensive, and it does not hold because the existing tool is annoying in ways you could live with.