Your problem isn't that you're missing a system.

When a company writes to me about building a system, the problem is almost never the one they describe. They tell me about a tool they're missing. What I find, most of the time, is that nobody ever wrote down how things get done in there.

That matters for one concrete reason: if you automate a disorderly process, you don't fix it, you speed it up. You end up with the same mess, faster, more expensive, and now harder to change.

What I almost always find

It isn't a lack of technology. It's a lack of guidance.

Nobody knows how something is done except the person doing it. The path an order takes, or an invoice, or a complaint, exists and works, but it lives in one person's head. When that person takes a holiday, the company improvises.

Nobody knows what's there. How many tools are being paid for, which spreadsheet is the real one, which of the three price lists is in use. There are answers, but you have to ask, and everyone answers differently.

Nothing is written down. I don't mean hundred-page manuals. I mean one page saying: an order comes in here, this person checks it, it gets recorded there, and it ends like this.

Those three things aren't solved with software. They're solved by deciding to sit down and write them.

Why the mistakes multiply

This is the part that strikes me most when I walk into a company like that.

The first mistake gets fixed. Someone finds the problem, corrects it, and adds an exception: "when the customer is this type, do it differently." Nobody writes down why. Six months later nobody remembers the reason, but the exception is still there.

The second mistake gets fixed the same way, adding another exception on top of the first. Now there are two rules that sometimes contradict each other.

Before long nobody can touch anything without breaking something. Not because the work is hard, but because the fixes piled up without memory. Each one solved that week's case and left a trap for the following year.

That's when I get the call. And that's when it pays to slow down, not speed up.

What happens if you build on top of that

Custom software does exactly what you tell it to do. If the process you describe is the tangled one you already had, you'll be paying to set that tangle in code.

Worse: the disorder used to be avoidable. Someone made an exception by hand and moved on. Once it's in the system, the exception has to be programmed. Every change that used to be a conversation is now a quote.

That's why my first question isn't what you want the system to do. It's how you do it today. If that question doesn't have a clear answer, it isn't time to build yet.

When you don't need custom software

I'll say it even though this is my job: often you don't.

If the process is simple and the problem is that nobody knows it, what you need is to write it down, not to buy something. One good page solves more than an application.

If what you do is done the same way by thousands of companies, a tool almost certainly already exists that solves it for a fraction of the cost. Invoicing, online sales, appointment booking. Building that from scratch is paying more for the same thing.

If the volume is still small, an orderly spreadsheet, with one person responsible and clear rules, holds up far longer than people think. The problem with the spreadsheet is rarely the spreadsheet: it's that there are fourteen of them.

In any of those three cases I'll tell you, and you'll save yourself the project. I'd rather that than build something that doesn't serve you.

When you do

When the process is clear, people know how it's done, and the tool still can't keep up: because volume grew, because what you do doesn't look like what everyone else does, or because you're paying in people's hours for something that should run on its own.

That's when software of your own pays for itself. Not before.

Where to start, whatever the project ends up costing

Write down how it's done today. One process per page, with names and owners.

You don't need to hire anyone for that, and it doesn't take weeks. If you do it, two things will happen: you'll find two or three problems on your own that you thought were about software and were actually about internal agreement, and if you later decide to build something, you'll be able to ask for it precisely instead of approximately.

That last part lowers the price and the risk of the project more than anything else you can do.

If you'd like, we can have that conversation at no cost and with no strings attached. Sometimes it ends in a project, and sometimes it ends in "sort this out first, let's talk in six months."