Checklist

What to consider before investing in custom software

The projects that stall halfway do not usually stall on the engineering. They stall on questions the business had never answered about itself.

Published on 5 min read

Nobody arrives asking for custom software. They arrive describing a mess: a spreadsheet three people edit at once, a tool that does most of the job, a workaround everybody stopped noticing years ago.

By the time investing in custom software looks like the obvious answer, the decision often feels made. And the build is rarely where these projects go wrong. What goes wrong is what nobody settled beforehand, and almost all of it sits on your side of the table rather than the developer’s.

What should you consider before investing in custom software?

Four things, and all of them before scope or price: whether you can describe the process without pointing at a screen, who is allowed to decide when two people disagree, what state your existing data is really in, and who owns the code, the accounts and the documentation afterwards.

Can you describe the process without opening the software?

Try saying it out loud. What arrives, who touches it, what has to be true before it moves on, what happens when something is missing.

Most businesses describe the normal case in two minutes and then spend the rest of the conversation on exceptions. Those exceptions are the project. A rule that runs “we invoice at the end of the month, except for the two clients where we don’t” has to become something explicit: a setting, a permission, a manual override that someone is allowed to use. Every one of those is a decision, and every decision you have not made is one somebody else will make for you by guessing.

You do not need a document. But if nobody in the business can explain the work without demonstrating it on screen, the first stretch of the project is discovery, and it is better to know that going in.

Who is allowed to decide?

Name one person. Give them the authority to say no on behalf of everyone else, and make sure they genuinely have time for it, regularly, not when it happens to suit.

This sounds like a formality and it is the single strongest predictor of whether a build finishes. Software forces questions the business has been comfortably avoiding: what a customer record actually is, which department’s version of a status wins, whether a job can exist without a price on it. If those questions go to a committee, they get revisited. Revisited decisions are how scope grows and how a half-built system ends up with two of everything.

What state is your data in?

Everyone underestimates this, including people who look at their data daily.

Data that is perfectly workable for a human is often unusable for a machine. The same customer entered three ways. Phone numbers with and without formatting. A notes field carrying meaning nobody ever wrote down. A status column where four of the values are typos of each other.

It matters twice over. Once because it has to be cleaned before it can move, and once because the new system will enforce rules the old one tolerated, which means it will surface everything that was quietly wrong. Take a sample of your records, a hundred or so, and read them properly before anyone quotes on migrating them. It is the cheapest thing you can do in the whole project.

Who owns it once it is finished?

The real question underneath “what if the developer disappears” is ownership, and it belongs in the agreement rather than in goodwill. Three things need your name on them: the source code, in a repository you can reach; the accounts, meaning the domain, the hosting and any third-party services registered to you rather than to an agency; and documentation another developer can read without a handover call.

Ask what it is built on, too. Something ordinary and widely used means the next person is easy to find. Something clever and rare narrows the field, occasionally to one.

What it will ask of you afterwards

Custom software is not a purchase that completes. Browsers change, platforms change, the services it connects to change, and something that is untouched for two years has not been stable, it has been drifting. Budget attention for that, not just for the build.

Expect the first version to be wrong in places. It is not a failure of planning; it is what happens when people use something instead of imagining it. The useful question for a supplier is how changes after launch are handled, because that is the part you will actually live with.

And if the process itself is still changing month to month, wait. Encoding a workflow you are still inventing means paying to make a decision permanent that you will reverse in the spring.

When the honest answer is smaller

If the tool you have does most of the job and the gap costs someone a handful of minutes a week, you probably do not have a software project. You have an integration, or a small automation, or a report that needs to exist. Those are cheaper to try and cheaper to abandon.

The projects that go well are the ones where the business arrives with a process it can explain, one person who can decide, and a realistic view of its own data. None of that needs a developer, and all of it makes the quotes you get comparable to each other.

If we look at it together and the conclusion is that connecting two tools you already pay for would do the job, that is what we will tell you.

Common questions

We tried this once before and it was never finished. What usually goes wrong?
Two causes account for most of it. Scope that was never cut, so the project kept growing while the appetite for it shrank. And a decision-maker on the client side who was named but never actually available, so questions sat unanswered and the work stopped at each one. Both are fixable, and both are fixed before the build, not during it.
Do we need a written specification before we talk to anyone?
No, and a specification written without a developer in the room usually describes the software you already have. What helps is being able to walk somebody through the process end to end, including the exceptions. The document comes out of that conversation rather than before it.
How do we know we are not being sold more than we need?
Ask what happens if you build only the first part and stop. If the answer is that nothing works until all of it exists, the scope is either genuinely indivisible or has not been thought about. A supplier who can name a smaller first version, and say what it would leave you without, is doing the work.
Is custom software only worth it for larger companies?
Size matters less than how odd the process is and how much manual work sits around the current tools. A two-person business with one unusual workflow can have a stronger case than a thirty-person one that runs like every other business in its field.