Build or buy? How to decide between custom software and a SaaS subscription
Every software decision eventually turns into the same argument. One person says, "Why would we build this? There must be a tool." Another says, "We looked at three tools and none of them do what we need."
Both can be right. The trick is knowing which situation you are in, and being honest about it, because the wrong choice is expensive in either direction.
Start by being fair to buying
Buying is the default for good reasons. You get something working this week. The vendor handles hosting, security patches, and bug fixes. Hundreds of other customers have already found the sharp edges.
If a decent product fits at least most of what you do, buy it. Do not build a worse version of something that exists, just because building feels more serious.
Where subscriptions quietly hurt
Subscriptions have a few costs that do not show up on the pricing page:
- They scale with you. Pricing per seat or per record feels fine at ten people. At a hundred it can be a line item that makes your finance lead wince.
- You rent the workflow. The vendor can change pricing, remove a feature, or shut down. Your process sits on top of their decisions.
- You adapt to it. The tool has a way of doing things. You start doing things that way too, even when it is not how you would choose.
- The gaps get patched by people. The thing the tool cannot do becomes someone's weekly chore. We talked about this in why custom software can beat off-the-shelf.
Where building hurts
Building is not free of pain either:
- You pay up front, and it takes time before anything is usable.
- You are responsible for it afterward, including bugs, updates and hosting. See what software costs after launch.
- If your requirements are unclear, you can spend a lot to build the wrong thing.
Anyone who tells you building is always cheaper in the long run is selling something. So is anyone who says it never is.
Five questions that usually settle it
- Is this core to how we compete, or is it plumbing? Plumbing (payroll, email, basic accounting) should almost always be bought. Core workflows are where custom pays off.
- How much of our process would we have to change to fit the tool? A little is fine. A lot means you are paying to make your business worse.
- What does it cost over three to five years, not three months? Add up subscriptions, add-ons, and the staff time spent on workarounds. Then compare it against a build plus upkeep.
- How hard would it be to leave? If your data and process are locked in, that is a risk with a price attached.
- Does it need to connect to other things? Many tools have integrations that look good in a demo and break in real use.
There is a middle road
It is not a binary choice. Plenty of good setups are a mix:
- Buy the standard parts, build the unique part. Use an off-the-shelf tool for accounting and email, and build the piece that is specific to your operation.
- Build a layer on top. Keep your existing tool and add a custom front end or automation that makes it behave the way you want.
- Start by buying, switch when it hurts. Use a product while you learn what you need. Then, with real experience, build what you now understand properly.
That last one is underrated. A year of using a tool tells you exactly which parts of it frustrate you, and that becomes a very precise brief.
A rough rule of thumb
If the software touches your customers directly, handles something no competitor does the same way, or will be central to your business for many years, building starts to deserve a serious look. If it supports your team in a generic way, buy.
When it is truly unclear, run a small experiment. Build the narrowest useful version, or trial the best tool for a month, and see what you learn. Our post on MVPs covers how to keep that experiment small.
Not sure which camp you are in? Describe your situation and we will tell you straight, even if the answer is "just buy the tool."
