There is a conversation we have several times a year. A contractor with somewhere between eight and eighty people is paying real money for a field service platform, most of the office hates it, the crews mostly ignore it, and someone has started asking whether they should just have something built. The honest answer is usually "not the whole thing" — but also not "no".
The packaged platforms are good software. They encode a decade of learning about how service businesses run, and they will beat anything custom on the parts that every service business does identically. The trouble starts where your business is not identical, which is exactly the part you are competing on.
Four ways a platform stops fitting
These get talked about as one complaint — "the software does not work for us" — but they have completely different remedies, and two of them do not involve building anything.
1. It is unconfigured, not unfit
The most common case by a wide margin. The platform was set up in a hurry two years ago by someone who has since left, half the job types are wrong, the price book was imported once and never touched, and nobody has opened the automation settings. This looks and feels exactly like a bad fit. It is not. It is a weekend of configuration and a week of retraining, and it costs a fraction of anything else on this list.
2. It fits the work but not the shape of the company
You run three divisions with different approval rules, or you are half service and half new construction, or you subcontract a trade and need those crews in the schedule without giving them your customer list. The platform assumes one operating model and you have two. Configuration cannot fix a structural assumption.
3. The pricing model fights your headcount
Per-seat pricing was designed for software where every seat is a full-time user. In the trades, a large share of your headcount touches the system for four minutes a day — a helper logging hours, a seasonal crew, an apprentice. You end up either paying full price for four-minute users or, far more commonly, sharing logins, which quietly destroys the audit trail and the job costing at the same time.
4. It cannot express the thing you are actually good at
This is the one that matters. Every durable small business has something it does differently — the way it prices a particular kind of job, a warranty program, a scheduling rule that keeps its best techs on the right work, a customer relationship the industry does not have a field for. Packaged software is an average of its market. Your edge is by definition not average, which is why the platform has no place to put it and it lives in a spreadsheet beside the platform.
What each failure mode is actually worth fixing with
| What is wrong | Proportionate remedy | Build anything? |
|---|---|---|
| Unconfigured, stale setup | Reconfiguration and retraining, possibly with the vendor's own team | No |
| Structural mismatch with the company | A second system for the division that does not fit, sharing customers | Sometimes |
| Per-seat cost against light users | A lightweight custom app for the four-minute users, writing into the platform | Yes, small |
| No place for your differentiator | Build the differentiating workflow; keep the platform for the commodity parts | Yes |
| Reporting that never answers the question | A read-only reporting layer over exported data | Yes, small |
The hybrid that usually wins
Rip-and-replace is almost never the right answer for a business under a hundred people, because the platform is genuinely carrying invoicing, payments, standard scheduling, and a mobile app you did not have to build. What works is keeping it as the system of record and building only at the edge where it does not reach.
01
Keep the platform as the record
Customers, jobs, invoices, and payments stay where they are. Nothing about this project should threaten the ability to bill on Friday, and any proposal that does deserves suspicion.
02
Sync out on a schedule
A service reads customers, jobs, and job states out through the API or a nightly export, normalizes them, and keeps the original identifiers attached so every record points home.
03
Build the workflow the platform has no field for
The estimating model, the maintenance program, the multi-division approval chain, the light-touch crew app. This is where the money goes, and it is small because it is only the missing part.
04
Write back through a queue
Changes that belong in the platform go out as explicit, idempotent operations, logged and reconciled against a read afterwards. The custom app never assumes a write landed.
05
Reassess seats after ninety days
Once the light users are on the custom app, count how many platform seats you actually need. This is often where the build pays for its own hosting.
The integration mechanics of that pattern — how data realistically gets out of a system you do not control, and what to do when there is no usable API — are covered in connecting a legacy system without replacing it.
Questions to answer before you spend anything
- Can we get our data out? Not "is there an API" — has anyone confirmed it exposes the objects and history you need, at a rate limit you can live with? Answer this first, because it changes every downstream option.
- What is the real annual cost? Seats plus payment processing margin plus the modules plus the hours spent working around it. Compare against a build's first-year cost and its ongoing maintenance, not just the build quote.
- Which part is genuinely ours? If you cannot name a workflow that is specific to your business, you probably need configuration, not software.
- Who owns it internally? Custom software with no owner rots exactly as fast as a stale platform configuration. If nobody has an hour a week for this, buy better instead.
- What happens if we do nothing for a year? Sometimes the honest answer is "it stays annoying", and that is a legitimate reason to wait.
Build the part of the process a competitor could not copy by buying the same subscription you did. Buy the rest.
The case for staying put
We tell people not to build fairly often. If your operation looks like most operations in your trade, if the complaints are about training and habit rather than capability, if nobody internally will own the result, or if the platform is carrying compliance and payments you would otherwise have to rebuild — stay. Spend the money on configuring what you already pay for and on the two integrations that remove retyping.
The build case is narrower than vendors of custom software like to admit, and it is strongest when it is smallest: one workflow, at the edge, connected to the system you keep.
Frequently asked questions
Is custom software cheaper than a field service platform?
Rarely on a like-for-like basis, and anyone promising that is comparing the wrong things. Custom becomes cheaper when it replaces per-seat licences for light users, or when it enables a workflow the platform cannot express at all. Compare total first-year cost plus ongoing maintenance, not the build quote against a monthly invoice.
Can we keep our existing platform and still build something?
That is the arrangement we recommend most often. The platform stays the system of record for customers, jobs, and invoicing; the custom app owns the workflow it has no field for and syncs both ways. It is smaller, cheaper, and far less risky than replacing a system that is currently billing your customers.
What if our platform has no API?
There are usually still four ways out: a scheduled report export, direct database or replica access, a file drop, or in the worst case a controlled screen-level integration. Confirm which one is available before scoping anything, because it determines how fresh the data can be and whether write-back is realistic.
How long does the edge-build approach take?
A single well-scoped workflow with a read-only sync typically reaches real use in weeks rather than quarters, because it is not trying to replace invoicing, payments, or scheduling. Write-back is deliberately added after the read path has run for a few weeks and surfaced the data problems nobody warned you about.