Why Small Businesses Benefit from Custom Software

A benefit is not a feature. It is the difference between a problem that keeps costing you and a problem that stopped. So this is not a list of good things custom software does. It is a way to look at your own operation and work out whether you have the kind of problem it fixes, because plenty of businesses do not.

Nobody can tell you the size of your benefit

You will find articles that give you a percentage. Ignore them. A figure like that came out of somebody else’s business, with their process, their people and their tools. It does not transfer to yours, and anyone quoting one at you is selling rather than informing.

What does transfer is the shape of a problem. If the shape matches, you can put your own numbers against it and get an answer that is actually about you. That is slower than a statistic and it is the only version worth having. Part one of this series covers what custom software is and is not; this part is about which problems are worth pointing it at.

What makes a problem worth building for

Four properties. A problem with all four is usually worth a conversation. One missing two of them usually is not, however annoying it is.

• It repeats. Software earns its cost on frequency, not on drama. A ten-minute task done twice a day costs more over a year than a two-hour task done twice a year. Do that multiplication before anything else.
• The rules are knowable. You can say out loud what happens, in what order, and who decides. It does not have to be written down yet. It does have to be something you could explain to a stranger in one sitting. If nobody in the building can state the rule, software cannot state it either.
• It has edges you can point at. The problem starts somewhere and ends somewhere. “Quote to approved job” has edges. “Everything about how we run” does not, and a project without edges is a project without an end.
• Somebody already feels the cost. A person complains about it, a customer waits on it, or a number turns up too late to act on. Problems nobody feels do not get used once they are solved, because the people doing the work were fine with how it was.

Problems that look the same and are not

These are the ones that turn into software nobody opens.

• A disagreement about how the work should run. Two people do the same job two different ways and neither of them is wrong yet. Software will pick one of those ways and make it the rule. Settle the argument on paper first, where changing your mind is free.
• A product you never finished setting up. Some of what people want built already exists in a tool they pay for and configured once, in a hurry, years ago. Go and look before you build. Dull answer, often the right one.
• A capacity problem wearing an information costume. If the constraint is that there are not enough hours in the bay, a better screen does not add hours. Software helps where the waste is in moving information around. It does nothing for capacity.
• Something rare that matters enormously. Rare and high stakes is usually a checklist and a second pair of eyes, not a system.

Sales tracking, inventory, client management

Three places a small business often ends up building something. Each can be a real problem or a false one, and each has a tell you can go and look for today.

Sales tracking. Renting a CRM is usually right. It turns into a real problem when your pipeline has stages a generic pipeline does not, so half the team keeps a private list because the shared one does not match the job. The tell is the private list.

Inventory. Counting stock is something products already do well. It turns into a real problem when your stock is not a simple count: material tracked by roll and by offcut, parts reserved against a job that has not started, the same item under three names because three suppliers name it three ways. The tell is the spreadsheet somebody keeps beside the system.

Client management. Storing contacts is a commodity. It turns into a real problem when the client record has to carry the work as well: which jobs, which files, what was promised, what is still owed. The tell is how long it takes somebody to answer “where are we on this”.

Scope sets the price, and being small helps you here

What a build costs is set by the size of the process, not the size of the business paying for it. A large company builds a large system because it has a large process to cover. One process, built once, costs what one process costs. A repair shop’s work orders. A forensic engineering firm’s case files. Neither of those is a company-wide system, and the bill follows the process rather than the letterhead.

The part usually left out is that on this kind of project, being small is an advantage.

• You can describe the whole process yourself. In one sitting, from memory, because you have done the job. A large organization has to interview its own departments to find out what its process currently is.
• The person deciding is the person doing the work. There is no department that owns the process and a second one that owns the budget. You change your mind on Tuesday and the change gets made.
• Nothing gets built to satisfy a policy. Big projects grow because parts of the organization have to be accommodated. Yours has nobody to accommodate, so the scope stays the scope.
• You find out quickly whether it worked. You are close enough to the work to see it for yourself. Nobody has to build you a report about your own shop.

What it costs to find out

You do not have to commit to a build to get a straight answer about whether you have one of these problems. Our numbers, not the industry’s: discovery starts at $1,500, a fixed fee credited against the build if you go ahead, and it produces a working prototype, a written scope and a firm price. A build starts at $15,000, with the scope and the price signed before work begins. Support is optional, from $1,000 a month.

What you hold at the end matters as much as what it cost. All deliverables are yours on final payment, and you get the full repository plus the documentation for deploying it. No lock-in. Whether renting or owning is the better deal for a given process is part three of this series.

The exercise to do before you talk to anyone

Pick the one process that annoys you most. Write down what happens, in order, and who touches each step. Then put two numbers next to every step: how many times a week it happens, and how long it takes.

Read it back against the four properties. Most of the time the page answers itself. If the answer is no, you have saved yourself a project and you can stop here. If it is yes, part seven covers what to do with that page next.