When Buying SaaS Beats Building Internally

Buying wins when the capability is mature, non-strategic, easy to export from, and cheaper to operate than a custom version. Building wins only when the boundary itself creates an advantage you need to own.

Compare the work left after purchase

Do not compare subscription price with development cost alone. For each option, write:

1. Setup and migration work.
2. Monthly operating time.
3. Support, training, and exception handling.
4. Data export and replacement path.
5. The cost of being wrong for six months.

If an external product handles 80% of an ordinary capability and the remaining 20% is not strategic, buy it and keep the configuration simple. If the missing 20% changes your customer experience, economics, or control boundary, build the smallest thin layer around it—not a full replacement.

Run the build-versus-buy decision

Google’s reliability material repeatedly treats simplicity and operational load as first-class constraints. That is a useful corrective for solo operators: more software can shift work rather than remove it. See the operating principle.

The reversible test

Choose one live use case. Run the external tool for 14 days with a documented export and a named owner. At review, record what it cost, saved, complicated, or revealed. If the evidence says the tool creates more maintenance than it removes, kill it before it becomes “the system.”