Should you build custom software or subscribe to SaaS?
The short answer
Subscribe when the job is standard and the product does it well — you get a mature tool, support and updates for a predictable monthly fee. Build when the process is what makes your business different, when you are paying for several subscriptions plus manual workarounds to do one job, or when per-user costs are growing faster than the value. Many businesses do both: SaaS for standard functions like accounting and email, and a focused custom system for the process that sets them apart.
Default to subscribing
For most business functions — accounting, payroll, email, file storage, standard sales pipelines — subscribing is the right answer. Somebody else has already solved the problem, maintains it, secures it and improves it. You would be paying to rebuild something worse.
The question is not “build or buy?” in general. It’s “is this particular process one where the standard product genuinely fits?”
When building starts to make sense
The process is your competitive edge. If the way you price, schedule, match or deliver is what makes you better than competitors, forcing it into a generic tool means working like everyone else.
You are stitching tools together. One process running across three subscriptions, a spreadsheet and somebody re-typing data in between is often more expensive in total than one system built for the job.
Per-user costs are outgrowing the value. Seat-based pricing is cheap for a small team and expensive for a large one — especially if most users only need one feature.
You need something no product does. A pricing engine tied to your market, a tool that checks supplier quotes against real costs, a database built from a specific public source. That’s when custom software tends to deliver its best returns.
Side by side
| Subscribe (SaaS) | Build (custom) | |
|---|---|---|
| Upfront cost | Low | Higher |
| Ongoing cost | Monthly fees that grow with users and tiers | Hosting, support and improvements |
| Time to start | Days | Weeks for a first version |
| Fit to your process | You adapt to the product | The product adapts to you |
| Ownership | You rent access | You own the code and data |
| Risk | Vendor changes prices or features | Depends on who maintains it |
The risks of each
SaaS risks: price rises, features moving to a higher tier, the product changing direction, and difficulty getting your data out if you leave.
Custom risks: a build that grows beyond its budget, and dependence on whoever maintains it. Reduce both by starting with a narrow first version, insisting that you own the code, data and accounts, and documenting the system.
The hybrid that often wins
Keep subscriptions for the standard parts and build only the piece that’s specific to you, connected to the rest. SinaTools, for example, needed pricing that responds to the market and a tool for testing supplier price rises — neither of which an off-the-shelf catalogue product offers.
How to decide
- Write down the process in a few lines and list the tools it touches today.
- Price the current setup honestly: subscriptions, workarounds and staff time.
- Check whether an off-the-shelf product genuinely fits — trial it on real cases.
- If it doesn’t, estimate the return on building (see how to calculate ROI).
- If you build, build the smallest useful version first.