Custom software is a program built for one business. Yours. Instead of signing up for a product that thousands of other companies also use, you describe how your work actually runs, and the software is built to match it.

Off-the-shelf software, and where it stops

Most software is off-the-shelf. It is a finished product. You sign up, you pay per user per month, and you get the same screens and the same rules as every other customer on that plan.

That is usually the right deal. Accounting, payroll, email and card payments work the same way at your business as they do at everybody else’s, and building your own version of them would be a waste of money.

Off-the-shelf stops working when the product and your business disagree. You need a field the product does not have. Your approval steps run in a different order than the product expects. Two systems each hold half of an answer and neither can see the other half. The usual patch is a spreadsheet on the side, or a person who retypes the same information into a second screen.

That patch is where custom software starts. Not with a grand plan. With a workaround that became permanent.

What actually gets built

Custom software is not one kind of product. It is whatever the job needs. Some of the shapes it takes:

A CRM that matches your sales process. Your stages, your fields, the follow-up you actually do, instead of a generic pipeline you translate in your head every time you open it.
A booking or scheduling system. One that knows your real constraints: which person can do which job, what equipment it needs, how long the work actually takes.
A quoting tool. Your pricing, your options, your terms. The approved quote becomes the job instead of being retyped into something else.
A dashboard. One screen that pulls the numbers out of the systems holding them, so a question gets answered without three exports and an afternoon.
An automation. A step that used to need a person copying something from one place to another, now running on its own.
An internal tool. The unglamorous screen your team lives in all day. Work orders, inventory counts, case files, inspections.

A sensible first project is one of these, not all of them.

What it looks like in practice

A vehicle wrap shop quoted from spreadsheets. Every quote started as a copy of the last one, edited by hand. Once a job was approved, nothing carried it forward, so knowing which vehicles were in the bay meant walking out to the bay and looking. The software built for that shop puts the quote and the job on the same record.

The same shape turns up everywhere with different nouns. A repair shop’s work orders. A forensic engineering firm’s case files. In each one the business already had a process. It was running on paper, on spreadsheets and in one person’s memory.

What custom software is not

It is not a replacement for everything you run. Nobody should build their own accounting package. Custom software covers the part of your work that no product covers properly, and leaves the rest alone.
It is not a permanent construction project. It gets built, then it is a tool you use. It needs upkeep the way a truck needs servicing, but the building stops.
It is not one enormous launch. A sensible first version covers one process for the people who do that process. What gets built after that is decided by what they run into.
It is not a platform you rent from whoever built it. At least, it should not be. That depends on what you sign, which is the next section.

Who owns it

This is the part people assume and should check instead. Before you sign anything, ask three questions and get the answers in the contract rather than in an email:

Who owns the code once the final invoice is paid?
Where does it run, and whose account is that?
Could a different developer pick it up and keep working on it?

For our work the answers are: you do, your infrastructure, and yes. You get the repository and the documentation for deploying it when the final payment clears. No lock-in.

Renting software versus owning it is the whole comparison, and it has its own article in this series.

How to tell whether you need it

Your current tools being imperfect is not a reason. Everybody’s are. The signals worth acting on are narrower than that:

Someone on your team spends hours every week moving information between two systems by hand.
Your most important process lives in a spreadsheet that one person understands.
You have stopped asking a question about the business because getting the answer takes too long.
You are paying for a tool whose main job is to connect two other tools.
Something a customer waits for is slow because a step behind it is manual.

If none of those sound familiar, keep what you have. Custom software is worth building when the workaround costs more than the software would, and not before.

Series: Understanding Custom Software