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. It should not 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.

This is not an argument against custom software. Obviously, I believe it can be valuable or I have made a spectacularly poor career choice. It is an argument for making sure the problem is worth everything that comes along with building it.

Buy Before You Build

The first question should not be, “What should we build?” It should be, “Has someone already solved this 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 shame in buying software. There is no special prize for owning every line of code involved in operating a business. The goal is to solve the business problem, not win an award for writing the most code. Sometimes good technical judgment is knowing which problems should remain someone else’s problem.

Sometimes You Should Wait

Buying software and building software are not the only two 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 the cost of a workaround is small, 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.

Another bad time to act is 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 have to 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. That is something solid enough to make a decision about.

When The Workarounds Become The System

Waiting also 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. Then 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. It is paying through employee time, mistakes, training, delays, and knowledge that lives exclusively in the heads of a few experienced people. The question is no longer whether the business can avoid paying. The question is whether deliberately built software would cost less than continuing to pay in all these other ways.

When Custom Software Becomes Reasonable

Custom software becomes reasonable when the operation itself is meaningfully different from what standard platforms support. There are 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 must 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.

The best candidates for custom software usually 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

There is a habit in software projects of comparing the purchase price of an existing product to the initial development estimate of a custom one. This comparison 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 business may dislike the recurring bill, but replacing that bill with custom software does not make the responsibility disappear. It moves the responsibility inside.

Ownership is not necessarily bad. Owning a system gives the business control over its priorities, workflow, integrations, data, and pace of change. That control may absolutely be worth it! But it cannot be separated from the responsibility no matter how much everyone would like to keep only the fun part.

The Decision

Custom software is not better than existing software. It is justified when the cost of forcing the business into existing software 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 software 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 of that comparison 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 an existing product not 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.

Wrap Up

Sometimes the best software decision is to do nothing. At least, not yet. I believed that before I owned Blueprint, and I believe it even more now that I have seen what responsible ownership requires.

Buy software when the problem is common, the compromises are reasonable, and the product handles responsibilities the business should not casually take on. Use simple tools while the process is still changing. Let a little annoyance remain if removing it costs more than living with it.

Build custom software 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.