I build custom tools for a living, and my honest default is still: buy the SaaS. Off-the-shelf software is cheap relative to build time, maintained by someone else, and good enough for most jobs. But there is a line where building your own quietly wins.
Buy when the problem is common
Email, invoicing, scheduling, accounting: thousands of businesses have the same need, so the market has solved it well and cheaply. Building your own version of a solved problem is a hobby, not a business decision.
Build when the problem is yours
The moment your process is specific to how you work, SaaS starts to chafe. You end up paying for features you do not use, bending your workflow to fit the tool, and stitching together exports between three subscriptions. That friction is the signal.
If you are paying per seat for software you only use 10% of, and duct-taping the rest, a small custom tool usually pays for itself fast.
The hidden cost of SaaS sprawl
The subscriptions are the visible cost. The invisible one is the glue: the exports, the copy-paste between tools, the one person who understands how it all connects. Five tools that each do 80% of a job leave a surprising amount of manual work in the gaps, and that work quietly eats hours every week.
The math that matters
Add up the monthly subscriptions you are working around, plus the hours your team spends on manual glue work. A focused internal tool is a one-time build with near-zero running cost, and it fits your process exactly. Often the payback is months, not years.
A simple test
Ask three questions. Is this process specific to how we work? Are we paying for far more than we use? Are we manually moving data between tools to make it work? If the answer to all three is yes, a small custom tool is probably cheaper and better than the stack you are holding together.
Custom does not mean a huge project
People picture months of development and a scary budget. Most useful internal tools are small: one screen that replaces a painful spreadsheet, one script that turns an afternoon of reporting into a click. The goal is not to build software for its own sake, it is to erase one specific bottleneck.
Wondering if your process is a build candidate? Here's how I approach it.