Off-the-shelf tool or custom software? A simple way to decide

The default answer to “should we build this ourselves?” should almost always be no. An existing tool has already been built, tested, and maintained by a team whose full-time job is that one problem. Custom software only makes sense when that default genuinely breaks down — and it's worth being honest about when that actually happens, rather than jumping to a build because it feels more impressive.

The bias should be: buy first

Most business workflows — CRM, invoicing, scheduling, support tickets — are solved problems. Paying a monthly fee for a tool that already works, is already secure, and gets updated without you lifting a finger is almost always the cheaper, safer choice than building and maintaining your own version of the same thing.

The actual signal it's time to build

The tell isn't “this tool is annoying.” Most tools are annoying in some way. The real signal is when you're spending more manual effort working around a tool's limitations than the tool is saving you in the first place — duct-taping three SaaS products together with spreadsheets and manual re-entry to approximate a workflow none of them were actually built for.

At that point the tool isn't reducing your manual work anymore. It's just relocating it.

A simple gut check

Add up the hours your team spends working around a tool's limitations — duplicate entry, manual reconciliation, exporting from one system to paste into another. If that number is climbing every month instead of shrinking, that's the actual signal, not how new or exciting a custom build sounds.

Why this is usually the last system we build, not the first

This is exactly why Software Engineering sits underneath AI Systems and Business Automation in how we're structured, not ahead of them. Custom software earns its cost once a workflow has actually outgrown what's available off the shelf — usually after an automation or agent is already live and has proven the workflow is worth investing in properly. Building it first, before that's established, is how teams end up maintaining expensive software for a problem that didn't need one.