Powstania Warszawskiego 15
31-539 Kraków
Most service companies reach this question after the third workaround. The scheduling tool cannot express who is allowed to take which job, so dispatch keeps a second board in a spreadsheet. The work order form cannot change by job type, so technicians write the part that matters into a notes field that no report reads. Everything still works, and none of it reports. This guide covers the build vs buy field service software question the way it actually presents itself: where that line sits in a real operation, the three places it shows up, and how to settle which side of it you are on using your own numbers rather than a vendor comparison table.
August 10, 20269 min readStart by conceding the obvious. Scheduling, customer records, invoicing, payment collection and standard reporting are solved problems, and they are solved by companies that have done nothing else for a decade. Rebuilding that from scratch is a bad trade in almost every case, and a supplier who tells you otherwise is quoting their own capacity rather than your situation.
The mistake is not buying the platform. The mistake is assuming that because it covers most of the operation on day one, it will stretch to cover the rest as you grow. Configuration takes you a long way. Then it stops, and what happens next is usually invisible in the software and very visible in the office.
The seam is the point where the platform's model of a service business stops matching yours. It almost never announces itself. It shows up as three small habits, each cheap on its own and expensive at volume.
Each of those is a symptom of the same thing: a rule your business runs on that the platform has no field for. Below are the three places that rule usually lives.
Every platform gives you skills tags, priorities and a calendar. That covers the simple version. This technician is certified for this equipment type, this customer is priority, this window is free.
What it handles badly is a conditional rule. Which technician may take a job depends on the certification, and on which parts are already on which van, and on the contract that customer signed, and on whether it is a callback on work someone else did last month.
Season changes the rule. A new service agreement changes the rule. The platform gives you one flat field where your business has a decision tree.
The wrong response is to rebuild the scheduler. The right response is usually narrower: build the layer that applies your rules and hands the result to the system you already pay for, so dispatch stops holding the logic in their head and in a spreadsheet.
Ask a service company to show you their work order and you will rarely be shown one form. You will be shown a different one per job type, sometimes per customer, sometimes per compliance requirement, and a stack of paper for the cases the software cannot express.
Most platforms do offer custom fields, and some offer conditional fields. What they very rarely offer is versioning. Your form changes in March because a customer added a required reading. In June you need to produce the January report, and it has to render under the January form, with the fields that existed then. Off the shelf tools tend to overwrite the definition and quietly reshape your history.
The same section usually carries the other operational specifics: a minimum number of photos before a job can close, a meter reading validated against the previous visit, a signature captured on the device, a value that must be rejected rather than saved when it is out of range.
None of that is exotic. It is simply specific, and specific is what off the shelf cannot be. If you are writing this down for a supplier, the practical shape of it is in our guide to a mobile app requirements document.
This is the seam where custom wins most often, and the one buyers underestimate most consistently, because it is invisible in a demo run over office wifi.
Offline reading is straightforward. Offline writing is where the engineering sits. Two people edit the same job from different vans and both come back into coverage. A photo upload starts on one bar of signal and stalls, which is worse than no signal at all because the app believes it succeeded.
The rest arrives with the shift. A form definition changed while a device was offline for two days. Background location and a long running timer drain a battery that has to last until evening. A job starts at 23:50 and finishes after midnight, and payroll has to decide which day it belongs to.
On TimeFix, the work timer had to keep counting when the technician locks the screen, and when the technician places a call from inside the app itself. That was not in the original assumptions and it did not come out of a specification conversation. It came out of technicians using the app on real jobs.
This is the pattern worth planning for rather than fearing: a meaningful share of field requirements only appear once the app is in the environment it was built for.
Keep the system of record. Build the app your technicians hold.
There are two reasons this split works. The first is adoption. Office staff will learn an awkward screen because they use it forty hours a week at a desk. A technician with dirty gloves, one bar of signal and a customer waiting will not, and a field app that crews route around produces worse data than the paper it replaced.
The second is specificity. The technician app is exactly the part that carries your rules, your forms and your conditions, which is the part off the shelf cannot reach.
One constraint decides whether this is feasible for you, and it should be checked before anyone scopes anything. Your existing platform's API defines what is possible: which objects can be written and not only read, what the rate limits are, whether it pushes events or has to be polled, and whether custom fields are exposed at all.
That check takes days, not weeks, and it belongs at the very start. It is the first thing we look at in an app discovery workshop when a client already runs a field service platform.
A first version is narrow on purpose. Today's jobs, the job detail, status changes, the form with its validation and photos, a signature, time capture, and an offline queue that survives a full day without coverage. That is a product technicians can use on Monday.
What waits for later: rewriting the dispatcher, inventory and van stock, the customer facing portal, analytics dashboards. Each of those is a real requirement for some operations and none of them decides whether version one succeeds.
The general logic for cutting a first release is in our piece on version one scope, and the vertical specifics sit on our field service app development page. What drives the number on the quote is covered separately in the five key cost drivers for field service apps.
Vendor comparison tables will not answer this, including ours. The measurement that does is small, and you can run it over five working days without telling anybody it is a software evaluation.
If almost nothing survives, buy, configure properly, and revisit in a year. If the same two items appear every single day, you already know which part of the operation needs its own software, and you now have a specification instead of a feeling.
The delays on field service projects are rarely engineering delays. They come from the client side, and they are predictable enough to plan around.
The commercial side of that is set out on our fixed price app development page, and the stage by stage version is in working with an app development agency. If you are also weighing who builds it, what to check before choosing a company covers how to read the answers you get.
Upfront, yes. Over several years it depends almost entirely on seat count and on what the workarounds are costing you in office hours. The honest comparison is not licence fees against a project quote. It is total cost including the reconciliation work, the chased forms and the data you currently cannot report on.
That is the usual arrangement. The platform stays as the system of record and the custom app writes into it. The deciding factor is the platform's API: what can be written, how often, and whether custom fields are exposed. That check comes before scoping, not after.
A narrow first version aimed at one workflow usually runs 10 to 14 weeks from kickoff. A fuller system with dispatch, integrations and a back office view runs 14 to 22 weeks. Both assume access and decisions arrive on time, which is the part that actually moves the date.
It is a real risk and it is managed by keeping the integration in one isolated layer rather than spreading vendor specifics through the app. Ask any supplier how they plan to isolate it, and ask what happens commercially if the vendor breaks something after launch.
That belongs in the contract in writing, alongside the acceptance protocol and what separates a defect from a change request. If a supplier is vague about ownership before signature, they will not be clearer about it afterwards.
Run the five day measurement first. If the result is ambiguous, a discovery workshop turns the operation into a scoped, priceable document, and a fair one will sometimes conclude that configuring what you already own is the better answer.
Co-Founder and CEO, Apps Value
Thomas takes the first call on most Apps Value projects. On field service work that call is usually spent separating the part of the operation a platform can already handle from the part that needs its own software. If configuring what you own is the better answer, he will say so on the call. If it is not, you get a written scope and a fixed price before a line of code exists.
Tell us how the work runs today and what the workarounds cost you. You will get a straight answer on which items your current platform could absorb with configuration, which ones justify building, and a written scope with a fixed price for whatever is left.
Book an intro call30 minutes, no preparation needed.