Should a plumbing company build custom dispatch software or buy ServiceTitan?

ServiceTitan, Housecall Pro, Jobber, FieldEdge and Service Fusion, or whatever you run, have spent years solving the boring parts a shop actually needs. Technician GPS, part inventory, price books, payment capture, membership billing, QuickBooks sync. Rebuilding that from scratch takes years a shop's margin cannot carry. It also produces software that is worse than what already exists.

The board of record is the single source of truth for jobs, customers, technician schedules and invoices. Owner-operators, service managers and CSRs already know how to work it. Ripping it out resets that muscle memory for every dispatcher and apprentice on the team. The rebuild still has to catch up to years of platform maturity.

So the honest starting position is: keep the platform, and ask a narrower question. What does it not do for your shop, and is the gap worth closing with a custom layer.

Three situations make a full custom build the right call instead of a layer on top. First, a multi-brand rollup where several acquired shops each arrive on a different FSM. Consolidating onto one platform can cost more in licensing and retraining than building one system that serves every brand. Second, a workflow the FSM genuinely cannot express: a pricing structure, a dispatch rule or a compliance record no configuration screen reaches. That gets confirmed by checking the platform's actual settings and API surface, never assumed from a demo.

Third, a business already centered on a spreadsheet or a home-grown ERP with no FSM behind it at all. There, the comparison is not custom versus ServiceTitan. It is custom versus adopting a platform for the first time. Either can be the right answer, depending on how far the spreadsheet has already been stretched to do a platform's job.

Outside those three, replacing a working FSM to fix a triage or reporting gap is solving the wrong problem at the wrong cost.

Housecall Pro and Jobber expose booking, customer and job data through published APIs a custom layer can write to directly. Building against either is mostly integration work: matching customers, creating jobs in the shop's own job-type structure, and handling the platform's own auth flow.

ServiceTitan is different. It needs developer-program API access, granted per tenant, plus the shop's own credentials, never a shared key across clients. That access gets confirmed during the audit, not assumed from a sales deck. A custom layer for a ServiceTitan shop has to register as its own developer organization. The shop's admin then approves the connection. ServiceTitan does not allow one app to run on a client's key on another vendor's behalf.

None of this changes the recommendation. It changes the order: confirm access first, scope the layer second, build third. A shop on FieldEdge, Service Fusion, an older FSM or a spreadsheet goes through the same sequence. Only the starting API surface changes. Sometimes there is none at all.