Build vs. Buy: When a Custom Internal Tool Beats Another SaaS Subscription
The default advice is always "buy, don't build." That's right for commodity software and wrong for the workflow that actually differentiates you. Here's the framework I use with clients before either option gets a signature.
Every SaaS vendor and half the tech blogs will tell you the same thing: buy, don't build. For most software, that's correct advice, and I say it to clients constantly. But I've also watched organizations stack a fourth, fifth, sixth subscription on top of a workflow that's core to how they operate, bending their actual process to fit someone else's product roadmap, because nobody stopped to ask whether this particular tool was a commodity or a differentiator. Those are different questions with different answers, and conflating them is where the money and the control both leak out.
What "buy" is actually right for
Buy the boring stuff. Email, payroll, calendar scheduling, video conferencing — commodity categories where every vendor solves the same well-understood problem, where switching cost is low, and where you gain nothing from owning the code. Nobody differentiates on a better internal email client. If a SaaS tool does exactly what you need out of the box and you're not bending your process to fit it, buying is the right call every time. The mistake isn't buying software. It's buying software for a workflow that isn't actually a commodity.
The tell that you're in build territory
I ask clients three questions before recommending either path. First: is this workflow the thing that makes you different from a competitor, or is it the same for every business in your category? If it's the former, a generic SaaS tool will always fit awkwardly — you'll spend your time working around its assumptions instead of the tool working around yours. Second: does the data this tool touches need to live somewhere you control, integrated with the other systems you already run — your LMS, your HRIS, your CRM — rather than trapped in one more vendor's silo? Third: are you already paying for three overlapping subscriptions to approximate one workflow, stitching them together with someone's afternoon and a spreadsheet? Any one of those is a signal. Two or three, and buying another SaaS seat is usually just deferring the real fix.
The cost nobody puts in the SaaS comparison
The build-vs-buy conversation usually gets framed as sticker price: the subscription's monthly fee against a developer's hourly rate. That's the wrong comparison. The real cost of "buy" is what you don't see on the invoice — the workaround your team builds around the tool's limits, the manual export-and-reimport step nobody counts as work, the day someone spends re-training the team when the vendor redesigns the interface, and the leverage you hand over the moment your process depends on a roadmap you don't control. I've built automation for clients who owned self-hosted n8n workflows instead of a vendor-hosted black box specifically because retryable, observable, client-owned infrastructure beats a cheaper tool you can't inspect when something breaks at 2am. The upfront number on a build is real and visible. The ongoing cost of a buy that doesn't fit is just as real and much harder to see coming.
What "build" actually looks like done right
Building doesn't mean a six-month platform project with a vague spec. The custom tools I build for clients start the same way the SaaS evaluation should have: what's the one workflow, what does it need to talk to, and what does "done" look like in a month, not a year. That self-hosted automation work is the clearest version of what "you own the system" means in practice: the client holds the workflows, can read exactly what runs and when, and can change a step without waiting on someone else's roadmap or absorbing a pricing change they had no say in. The NYU College of Dentistry relationship has run since 2018 on this same posture — build for the handoff, stay for the iteration, not drop-and-invoice. That only works because what got built was actually owned, not licensed.
A workable decision path
Before signing another annual contract, walk the workflow through this sequence: name the workflow specifically, not the department. List every tool currently touching it, including the spreadsheet nobody admits is load-bearing. Ask whether this workflow differentiates you or is genuinely commodity. If it's commodity and one tool does the whole job cleanly, buy it and move on — don't overthink a calendar app. If it's core to how you operate, touches data you need integrated elsewhere, or is already being stitched together from parts that don't quite fit, scope a build around that one workflow only. Don't build a platform when you need a feature.
Neither answer is a badge of honor. I've told clients to cancel a build conversation and just buy the tool, and I've told clients that the SaaS stack they were about to renew was actively working against them. The point isn't to build more. It's to stop defaulting to "buy" for the one workflow where owning the system is the actual competitive advantage.
Frequently asked questions
Isn't building always more expensive than a SaaS subscription? Not once you count the full cost of the buy option — the workarounds, the re-training when the vendor changes the UI, and the leverage you lose when your process depends on someone else's roadmap. For a commodity tool, buying still wins on cost. For a workflow you're already stitching together from three overlapping subscriptions, the SaaS math stops being cheaper than it looks.
How do I know if a workflow is "core" enough to justify building? Ask whether it's the same for every business in your category or whether it's part of what actually differentiates you. If a generic tool would look identical at your competitor's company, it's commodity — buy it. If you're bending your real process to fit someone else's assumptions, that's the signal to scope a build.
Do I need a full platform to get the benefit of building? No. Most of the value comes from scoping a build around one specific workflow — not a platform migration. Start with the single workflow that's costing you the most in workarounds, ship that, and decide whether the next one is worth building too.