Custom software or off the shelf? How I decide with owners.

On October 9, Deno, the company behind a popular programming runtime, announced that its team is joining Cloudflare. In Deno's own announcement, its hosted service, Deno Deploy, will keep running for six months and then shut down, with paying customers offered help moving to Cloudflare. The runtime is to get monthly bug-fix and security releases for one year, after which development ends. It stays open source. Deal terms were not disclosed (Deno announcement; Cloudflare announcement).

You may never touch either product. The lesson still applies to every owner: when your business runs on someone else's software, their plans can change yours. A sale, a price rise or a shutdown, and suddenly you are moving.

That does not mean you should build everything yourself. Most of the time you should not. The real question is which pieces to buy and which to build.

A common bottleneck: forcing your process into a tool that does not fit

I see two opposite mistakes. One owner bends a good process to match a tool, and the team works around it every day. Another owner pays for custom software to do something an off-the-shelf tool already does. Both are decisions made without a test.

How to decide: four questions

For any bottleneck, ask:

• Does a tool already do this? Invoicing, scheduling, email and accounting are solved problems. Buy one and move on.
• Does it fit how we really work? If your team needs three workarounds, it does not fit.
• Is this part of what makes us different? If it is, you probably want to own it.
• What happens if the tool goes away? Can you export your data today, and could someone else do the job?

If the first answer is yes and the second is yes, buy. If the work is particular to your business, or the tool fails the fourth question, that is when a small piece of custom software makes sense.

How it gets built, and stays fixed

When the answer is build, the goal is small, not grand:

1. Describe the one bottleneck. Triggers, steps, who is involved, what done looks like.
2. Keep buying what is commodity. Use your existing tools for the common parts.
3. Build only the connecting piece. The glue that makes your tools match your process is usually small.
4. Own it and write it down. You hold the code, the data and the notes on how it works.
5. Plan for change. Tools will be bought, renamed and shut down. A good build expects that.

Why I do it this way

I build software and run my own products, so I have been on both sides: relying on other people's platforms and owning the pieces that matter. I would not tell anyone to avoid ready-made tools. I would tell them to know which ones their business cannot afford to lose. Projects get a fixed quote before any work starts, and I reply to every message myself.

What "fixed for the long term" means

It means a vendor's roadmap cannot break your process without you seeing it coming. You can export your data, you know who owns each piece, and swapping a tool is an afternoon of work, not a crisis.

What I would do on Monday

List the five tools your business depends on most. Next to each, write one line: can I export my data today? If any answer is no, that is where to look first.

Show me yours

Bring the bottleneck, and the tools around it. On the free call you describe your week, I tell you honestly whether to buy or build, and you leave with one place to start. No obligation.

Show me yours. Text (512) 337-9530, email josh@joshdlange.com, or book the free AI assessment.

Sources: Deno, announcement; Cloudflare, "Deno joins Cloudflare". Checked October 14, 2026.