You Probably Don’t Need Custom Software

Introduction

I own Blueprint, and I regularly tell businesses they should not build custom software.

That sounds like a fairly bad sales strategy. Maybe it is! But custom software is expensive to build, and it creates a long-term responsibility for the business that owns it. I don’t think it should be the default recommendation every time existing software is annoying, requires a few compromises, or has a button in the wrong place.

A lot of business software is boring on purpose. Payroll, accounting, payments, scheduling, customer relationship management, and inventory are common problems shared by thousands of organizations. There are companies that have spent years (and a heroic amount of money) handling the unhappy paths, regulations, security problems, integrations, and strange edge cases in each of these areas. Rebuilding all of that because one part of the product is irritating is usually a bad trade.

Obviously, I believe custom software can be valuable or I have made a spectacularly poor career choice. I just think the problem should be worth everything that comes along with building it.

Buy Before You Build

Before asking what to build, find out whether someone has already solved the problem well enough.

Well enough is important. Existing software does not have to mirror every detail of how a business operates today. It has to solve the problem at an acceptable cost without damaging something that makes the business meaningfully different.

An existing product is probably sufficient when:

• The process is common across many businesses. If most organizations perform the work in roughly the same way, there is probably a mature product built around it.
• The company can reasonably adapt to the product. Sometimes the software is not wrong. A company has simply done something the same way for a long time, which does not necessarily make it the right way. A small process change is often much cheaper than a permanent software project.
• The software is not central to the company’s competitive advantage. A slightly better internal vacation request form is unlikely to change the trajectory of the business.
• A mature platform already owns specialized concerns. Security, compliance, payments, payroll, and accounting all contain sharp edges that are easy to underestimate. Paying a vendor whose entire business depends on handling them correctly is often an excellent deal.

There is no special prize for owning every line of code involved in operating a business. The goal is to solve the business problem. Sometimes good technical judgment means deciding that a problem should remain someone else’s problem.

Sometimes You Should Wait

Buying and building are not the only choices. Sometimes the right decision is to keep doing what the business is doing today and wait. A problem can be real and annoying and still not be worth solving with software right now.

If a workaround costs very little, changing the system around it may cost more than the workaround ever will. A few manual steps performed once a month are not automatically a software opportunity. Sometimes five minutes of annoyance is five minutes of annoyance. Buying a product introduces licensing, setup, training, migration, and usually some new annoyances to replace the old ones. Building something introduces even more.

I would also wait when the business is changing too quickly to define what it needs. Software makes decisions concrete, which is useful when a business understands its work but expensive while it is still discovering it. Building custom software around a process that changes every few weeks is a wonderful way to deliver exactly what the business no longer needs. Buying a product too early can have a similar effect by shaping a process before anyone knows what that process should be.

Waiting does not mean ignoring the problem. Keep track of the time spent, mistakes made, exceptions discovered, and which parts of the process keep changing. A spreadsheet, a form builder, or even a checklist may be enough while the business learns. Eventually the same steps start repeating, the exceptions become less surprising, and the cost becomes easier to see. Now there is something solid enough to make a decision about.

When the Workarounds Become the System

Waiting has a limit. Existing products are built around a model of how their customers usually operate. That model is what makes the product affordable across many customers. It is also what eventually creates friction for a business that does not fit it.

The first workaround is usually harmless. Export a CSV, change a column, and import it somewhere else. Then someone adds a spreadsheet with a couple of formulas. Another person creates a checklist explaining the spreadsheet. Six months later there is a shared folder containing three spreadsheets, a macro written by someone who left the company, and a warning in bold red text that says never to sort column F.

Congratulations: the business has built custom software. It simply built it accidentally out of products that were never meant to be an application. This unofficial application often has no clear owner, no meaningful validation, no automated tests, no history of why decisions were made, and no protection against someone deleting a formula.

Employees become the integrations between systems. They copy the same customer, order, or project information from one screen into another and then everyone is surprised when the systems disagree.

At this point, the business is already paying for custom behavior through employee time, mistakes, training, delays, and knowledge that lives exclusively in the heads of a few experienced people. Deliberately built software may cost less than continuing to pay in all of those other ways.

When Custom Software Becomes Reasonable

I start taking custom software seriously when the operation itself is meaningfully different from what standard platforms support. A few signals I look for:

• Employees repeatedly enter the same information into multiple systems. People make expensive and unreliable integrations.
• Workarounds have become an unofficial internal application. Spreadsheets, email rules, documents, scripts, and institutional knowledge are now holding an important process together.
• The process creates meaningful competitive advantage. If the way the business performs the work is part of why customers choose it, forcing that work into a generic model may remove the thing that makes it valuable.
• Existing software requires extensive customization but still does not fit. Paying heavily to fight a platform can be worse than owning a smaller system designed around the actual work.
• The company has enough process maturity to define what should be built. The people doing the work understand the normal path, the exceptions, what changes often, and what must remain stable.
• Inefficiency, errors, or missed opportunities cost more than development. The pain should be meaningful enough that fixing it produces a return, not merely relief.

Frequency matters too, probably more than people expect. A bad process performed twice a year is probably tolerable. A bad process performed hundreds of times a day is a product roadmap. Saving one person ten minutes once is not valuable, but saving twenty people ten minutes every day may be. Preventing a rare typo may not justify a system. Preventing a recurring mistake that causes refunds, compliance problems, or lost customers probably deserves a serious look.

In my experience, the best candidates for custom software are not dramatic greenfield ideas. They are known, repeated, expensive problems. The business has already proven the need because people are performing the work today. It can point to the delays, duplicate entry, failures, missed revenue, or awkward customer experience. The opportunity is not theoretical.

Custom Software Is Not a One-Time Purchase

Software projects have a bad habit of comparing the subscription price of an existing product with the initial development estimate of a custom one. That is tremendously unfair to the purchased product because custom software has to be owned.

It needs hosting, monitoring, security updates, backups, support, documentation, testing, and people capable of changing it. Browsers change. Operating systems change. Vendors change their APIs. Regulations change. The business itself changes. Even software that was perfectly designed for the business on day one will drift away from it if nobody continues to care for it.

This is part of the reason mature platforms can be such a good value. Their subscription price includes an organization accepting many of these responsibilities. The recurring bill may be annoying, but replacing it with custom software does not make the responsibility disappear. It moves the responsibility inside.

That being said, ownership gives the business control over its priorities, workflow, integrations, data, and pace of change. That control may absolutely be worth it. The business also gets the hosting bill, support queue, security work, and every future conversation about what the software should do next. It is a package deal.

The Decision

I think custom software is justified when the cost of forcing the business into existing products becomes greater than the cost and responsibility of owning a custom system.

That cost is larger than license fees. On the existing software side it includes employee time, duplicate entry, errors, delayed work, missed opportunities, awkward customer experiences, and expensive customizations that still fail to fit. On the custom side it includes discovery, development, hosting, security, maintenance, support, and the opportunity cost of every other thing the business could have funded instead.

Neither side is perfectly knowable. There is no crystal ball hiding in this exercise. But writing the costs down makes the conversation much more honest than declaring that a product “doesn’t work for us” or that custom software will “pay for itself.”

I generally want to know:

1. What does the current process cost today?
2. Which part of that cost would software actually remove?
3. Why can’t an existing product remove it?
4. How stable and well-understood is the process?
5. What would become clearer if the business waited?
6. What does the business gain by owning the solution?
7. Who will care for it after the first version is delivered?

If those questions do not have convincing answers, the business probably does not need custom software. At least, not yet.

Buy software when the problem is common and the compromises are reasonable. Use simple tools while the process is still changing. Let a little annoyance remain if removing it costs more than living with it.

Build when the business has learned enough to know where existing products truly fail, the way it operates is meaningfully valuable, and the cost of continuing to force the work into those products has become greater than the responsibility of owning something new.

Custom software should earn its way into a business.