Custom software or off-the-shelf SaaS: how to decide
Buy when your process is standard. Build when it is your advantage, or when spreadsheets glue three tools together. The questions that settle it.
The short answer
Buy software when your process is standard and the tool does it well. Build software when the process is part of how you compete, or when you have reached the point where three subscriptions and a set of spreadsheets are pretending to be one system.
That sounds obvious. The difficulty is that a business sits in between, and the cost of staying there is invisible because it is paid in staff time rather than invoices.
The decision in one table
| Question | Leans buy | Leans build |
|---|---|---|
| Is this process the same in most companies like ours? | Yes | No, it is how we differ |
| How many tools does this process touch today? | One | Three or more, plus spreadsheets |
| Do staff work around the tool daily? | Rarely | Constantly |
| Does the subscription grow with every hire? | Acceptable | Painful already |
| Can we export our data completely, today? | Yes | No, or only partly |
| Would a vendor change break us? | Inconvenient | Existential |
| Is the process stable? | Still changing | Well understood |
Count the right column. Two or fewer: buy, and stop feeling bad about it. Four or more: scope a build. Three: the interesting case, usually solved by buying the standard part and building the connecting piece.
When to buy without hesitation
Accounting, email, calendars, payroll, document storage, video calls, a standard CRM for a standard sales process. These are solved problems with mature products. Building any of them is a hobby, not a strategy.
When to build
- The process is your advantage. The way you quote, plan, deliver or follow up is different on purpose and customers notice. Forcing that into a generic tool sands off the difference.
- The spreadsheet has become a system. Shared, with formulas nobody dares touch, referenced in every meeting, and one wrong paste away from disaster. That spreadsheet is a specification for the tool you actually need.
- You are paying for the connections. Four subscriptions, an automation tool to move data between them, and a person who fixes the sync every week. The connecting layer is where custom software earns its keep.
- Exit is not possible. If your data cannot be exported cleanly, you do not own your process anymore. Building the core in software you own is how you get it back.
The usual answer: both
Companies end up with a mix. Standard tools for standard processes, and a piece of custom software in the middle that holds the process that makes them different, and talks to the standard tools through their APIs. That middle piece is typically a client portal, an internal planning tool, a quoting system, or a dashboard that finally shows one truth instead of four.
What this means for you
List the processes that annoy your team. For each one, run the table above. Buy the standard ones this month. For the one or two that lean build, describe the process end to end, including the spreadsheet, and get it scoped. A scope conversation costs an hour and tends to end with a smaller first version than anyone expected, because most of what people ask for turns out to be the second version.
Frequently asked questions
Isn't custom software always more expensive?
Upfront, yes. Over five years, not necessarily. Per-user subscriptions grow with your team, add-ons accumulate, and the hours spent copying data between tools are real. Custom software is a one-off build plus predictable maintenance, and it does exactly your process. Compare five-year totals for your actual situation.
What if the vendor already covers eighty percent of what I need?
Then the question is the remaining twenty percent. If it is cosmetic, buy. If it is the part that makes your business different, or the part that forces staff into workarounds every day, that twenty percent is where the cost hides, and building may be cheaper than living with it.
Can I start with SaaS and build later?
Often the right order. Use the tool, learn what your process really is, then build when the limits are clear. Make sure you can export your data cleanly before you sign, because the migration later depends on it.
How long does custom software take to build?
A focused internal tool that replaces a spreadsheet is a matter of weeks. A client portal or a multi-role system is months. The largest factor is not the code; it is how clearly the process is defined and how many systems it must talk to. We scope that first.