Build vs. Buy: When SaaS Is the Right Answer

Two failure modes exist here, and they cost about the same amount of money. The first is building custom software when a fifty-dollar-a-month tool already does the job. The second is renting three overlapping subscriptions and retyping data between them by hand for years, when a bridge between them would have paid for itself in the first year.

Neither documented engagement behind this site started from “let’s build something custom.” Both started from a specific, named gap in what off-the-shelf tools do.

When Off-the-Shelf Wins

The workflow is standard. If thousands of other businesses solve the same problem the same way, a vendor has already built it well. A plumbing company managing invoices, crews, and job scheduling has Jobber and Housecall Pro as genuine, mature options. See /guides/when-you-should-just-buy-jobber for the specific case, taken from a real HVAC project’s own pre-build research, where the honest conclusion was to recommend the off-the-shelf product over custom on pure feature-for-dollar terms.

The price is proportionate to the crew. A three-person crew company paying a few hundred dollars a month for scheduling and invoicing, and saving real office hours against a paper process, is a tool that has already paid for itself. The economics only tip toward a custom build once seat counts or feature gaps push the subscription cost close to what a one-time build would cost over several years; see /tools/cost-of-per-seat-software for that specific maths with your own numbers.

Nobody on staff can own custom software. A custom system needs someone who understands what it does and can flag when something looks wrong, even if the day-to-day maintenance is handled elsewhere. A two-person office with no capacity to be that person is a strong argument for staying on a maintained SaaS product.

When Custom Earns Its Keep

A specific business rule that no vendor sells. The HVAC engagement behind this site needed automatic overtime calculation against Ontario’s Employment Standards Act rules, shown on a signed document the technician and customer both see, and a QuickBooks Desktop integration that the client was never going to leave. No mainstream field-service SaaS product does the first two, and QuickBooks Online migration was never on the table for the second. That combination is what made the custom build the right call, not a general preference for custom over off-the-shelf.

You already pay for overlapping tools and retype between them. The fire-safety inspection engagement replaced carbon-copy paper work-order books, an Excel invoicing template, a Word quoting template, and group-chat dispatch, none of which talked to each other, with a single system. The cost of that rebuild was measured against the ongoing cost of staff time spent re-typing the same job information three or four times per job, not against a single SaaS subscription.

A legacy system you cannot or will not leave. QuickBooks Desktop, in the HVAC case, was never going to be replaced, because the client’s accounting workflow was already built around it. The integration had to be built to meet that system where it was (qbXML over the Web Connector, with cent-match reconciliation and a guard against double-invoicing), rather than asking the client to change accounting platforms to fit a vendor’s integration list.

Legacy data that has to be trusted before anything new can run. The fire-safety engagement’s roughly-490-row accounts-receivable spreadsheet had to be independently re-derived and corrected before a single new invoice could go out. That is not a problem an off-the-shelf tool’s import wizard solves; it needed a scoped, adversarial data-cleanup pass as its own piece of work.

The Honesty Test

Before recommending a custom build, the first question is always: does a vendor already solve this, and if not, is that gap actually worth paying to close?

If a mainstream tool is 85 percent of the way there and the missing 15 percent is a minor inconvenience, building a replacement for marginal gains creates a maintenance burden nobody asked for. If the missing 15 percent is a compliance rule, a legacy system you cannot leave, or years of untrustworthy data blocking every other decision, that is a different conversation, and it’s the one both documented engagements behind this site had.

The Rule of Thumb

If a mainstream vendor already does it well, use the vendor. If you are retyping data between three tools that don’t talk to each other, or your workflow needs a rule no vendor sells, that is when a scoped conversation about a custom build makes sense. See /pricing for what that conversation looks like.