Buy it, build it, or leave it alone

The question usually shows up as one of two sentences. “What tool should we buy for this?” Or, now that more people know software can be built quickly, “Could you just build us something?”

There’s a third answer, and nobody’s selling it. Leave it alone.

Nobody earns a subscription fee or a project fee when you decide a problem isn’t worth solving. So it rarely gets said out loud. I think it should be the first option on the table, not the last.

Is the problem worth solving at all?

Before buy versus build, I’d want a rough number on what the problem costs right now. Not a feeling. Minutes per time, times per year, how many people do it, and what happens when it’s done wrong.

I wrote about the math on small repeated tasks separately. The short version is that frequency matters more than how annoying something feels. A task done every day by three people is a different problem from a task one person does once a month, even if they hate both equally.

Then two more questions.

What happens if it goes wrong? A late internal report is irritating. A wrong invoice or a missed booking costs money and trust. The higher the cost of a mistake, the more the fix is worth, and the more carefully it has to be done.

Is this about to change anyway? If you’re switching vendors next quarter, or the person who does the task is rewriting the process, I’d wait.

If you can’t put any number on the problem, you can’t judge whether a $40-a-month tool (a made-up price, for illustration) or a custom build is worth it. You’d just be guessing in a more expensive way.

When would I leave it alone?

More often than people expect.

When the task is rare. When the workaround is ugly but works. When the real problem is a policy or a person and software would just make the confusion faster. When the fix would need more upkeep than the task takes.

Sometimes the honest answer isn’t software at all. A template, a shared checklist, or deleting a step that nobody reads anymore. Those are fixes too. They just don’t come with an invoice.

When would I buy?

When the problem is one that almost every business has.

Payroll, accounting, scheduling, email, file storage. Thousands of companies have the same need, so somebody has already built the software, already found the edge cases, and already pays people to keep it running. That last part is the one that matters. When you buy, the vendor carries the upkeep.

What you give up is fit and control. Off-the-shelf software works the way it works, and you’ll bend your process to it. The price can go up. Features you depend on can disappear. And your information now lives somewhere you don’t run.

That last point deserves more attention than it gets. The FTC’s Start with Security guide tells businesses to keep a watchful eye on service providers, put security expectations in the contract, and verify that the provider is actually meeting them. Its line on this is blunt: “Security can’t be a ‘take our word for it’ thing.” The guide is written for companies handing personal information to vendors, which describes any small business that signs up for a tool holding its customer list.

Then there’s getting out. In 2023 the FTC asked for public comment on cloud computing business practices and summarized what it heard. Some commenters said fees for moving data out of certain cloud services could discourage customers from switching providers. Others said minimum-spend contracts act as a lock-in mechanism. Those are claims from public comments about large cloud providers, not findings about the tool your office uses. But the shape is the same at any size. Before I signed up for anything that would hold my customer records, I’d check how I’d get them back out, in what format, and what it costs.

When would I build?

When the work is specific to how you do things, and the way you do it is part of why customers pick you.

If off-the-shelf software would force you to change something that matters, or you’d be paying for a large product to use one corner of it, building starts to make sense.

I build software with AI regularly, and building has gotten a lot cheaper. I can build and test ideas now that used to need a full development team. I think that’s real, and it moves the line. Things that were never worth building for one business can be now.

But building is the cheap part. Owning is the expensive part, and that hasn’t changed nearly as much.

Robert Glass, writing in IEEE Software in 2001, put maintenance at about 40 to 80 percent of software costs, around 60 percent on average. He also said about 60 percent of maintenance is enhancement, adding new capability, rather than fixing bugs. That’s a 25-year-old summary of research on traditional software projects, not a measurement of a small tool built last month. I wouldn’t quote the number as current. I’d take the direction seriously. Most of what software costs comes after it works.

Building got cheaper. Owning software didn’t.

In practice, owning means a few things. Somebody has to know the software exists. Somebody has to notice when it’s wrong. Somebody has to fix it when the tool it depends on changes. And the people using it will ask for one more feature, which is the enhancement part of Glass’s point.

Building also moves the privacy question onto you. If your custom tool holds customer information, you’re the one the FTC’s Protecting Personal Information guide is talking to. Its five principles are plain: take stock, scale down, lock it, pitch it, plan ahead. “Keep only what you need for your business” is easy advice to give and easy to forget when you’re building something and it’s tempting to save everything.

Control and responsibility come in the same package. That’s not a reason not to build. It’s the price.

How would I make the call?

In order:

1. Put a number on the problem. Rough is fine. If the number is tiny, stop.
2. Ask whether it’s yours or everybody’s. If every business has it, look for something to buy first.
3. Ask who keeps it running in two years. For a purchase, that’s the vendor, and you’re trusting them. For a build, it’s you or someone you pay. If nobody, don’t build it.
4. Ask where the data goes and how it comes back. Before signing up or before writing the first line.
5. Try the most reversible option first. A month-to-month subscription, a template, a small build you can throw away. Big commitments can come after you know it helps.

None of this needs a consultant. It needs an afternoon and some honesty about how often the thing actually happens.

If I had to compress it to one sentence: buy the problems everybody has, build the ones only you have and can afford to keep, and leave the rest alone. The hardest of the three is the last one, because it’s the only answer nobody gets paid for. If you’re stuck on which bucket something falls into, that’s the kind of question I like talking through.