Powstania Warszawskiego 15
31-539 Kraków
Field operations
Most service companies should stay on a packaged field service platform. A minority should not. The line is not company size or budget. It is whether the thing that decides your invoice can be expressed inside somebody else's product, and whether your technicians have quietly built a second system to work around the one you pay for.
Key takeaways for operations leaders
Packaged field service platforms are good products. They handle scheduling, dispatch, work orders, invoicing and customer notifications for a very wide range of service businesses, and for most companies buying one is the correct decision for years.
Outgrowing one rarely feels like a system failure. There is no outage and no crisis. Instead the office builds a spreadsheet next to the platform. A supervisor keeps a list of the accounts that need special handling. Technicians start writing things down in a notes app because the form in front of them cannot record the thing that just happened on site.
Each workaround is small and reasonable. Together they mean the software you pay for is no longer the record of your operation, and the real record lives across four places that do not reconcile.
The six signals below are the ones that have actually preceded a custom build in the projects we have delivered. They are meant to be read as a filter in both directions, because most companies that check one signal should stay exactly where they are.
Signal one
This is the strongest single predictor we see. In contracted service work, especially in custom HVAC software development, the money question on every visit is whether the work was covered by an agreement, covered under warranty, or fully billable. That decision runs on your own contract terms, your own exclusions, and your own history with that customer.
Generic platforms model this as a flag or a customer tag, because the vendor cannot ship every service agreement structure in the market. So somebody in the office reviews the visit afterwards and decides what to bill. That review is the cost. It scales with volume and it is where margin quietly leaks.
Signal two
Most field service products organise everything under the customer account. That is right for home services, where the address is the subject and each visit is largely self contained.
For maintenance and inspection work it is wrong. The subject is the unit: this chiller, this lift, this meter, this vessel. What matters is the full history of that unit across visits, technicians and years, including what was replaced, what was flagged and what was deferred. When your team reconstructs that history by reading through visit notes, you are storing your most valuable operational data in free text.
Signal three
The first question we ask when a client says the app has to work offline is whether their definition matches ours, because offline means at least three different things and the price depends entirely on which one.
Seeing today's assigned jobs without a signal is the easy version and most platforms cover it. Completing a full visit in a basement or a plant room, capturing readings, photos, parts used and a signature, then having all of it arrive intact and in order hours later, is a genuinely different piece of engineering.
If your crews work where coverage fails and the packaged app loses their input, that is not a configuration problem you can escalate to a vendor.
Signal four
On one of our field projects the technicians began keeping records in the notes app on their phones before the software covered a particular case. It was sensible behaviour and it created exactly the problem you would expect, which is a divergence between what happened and what the system says happened.
This is the signal to take most seriously, because it is evidence rather than opinion. Technicians do not maintain a second record for fun. They do it when the tool in their hand takes longer than the paper it replaced, or when it has no field for the thing they need to write down.
Adoption is the real risk in field software, and a workaround is adoption failing in slow motion.
Signal five
Many service businesses run their real system of record in an ERP or an accounting platform, with the field tool bolted onto the side. That is fine while data flows both ways.
It stops being fine when your team keys the same job into two systems, or when the field platform cannot receive the customer, contract and pricing data that would let it make the coverage decision from signal one.
At that point you are paying for a product and also paying people to be its integration layer. A custom build is worth pricing here not because the field app is exotic, but because owning both ends of the integration is often the only way to close the loop.
Signal six
Per technician pricing is fair when you use the platform broadly. It becomes a poor trade when your crews touch four screens out of forty, and those four screens are the ones that do not quite fit. Seat cost then scales with headcount while the value stays flat, and every new hire increases the cost of a compromise you already made.
This signal alone is not enough. Licence arithmetic on its own is a weak reason to build, because a custom app has its own lifetime cost in maintenance and support. It becomes decisive when it sits on top of two or three of the signals above.
One signal is a workaround. Three signals is an operation that no longer fits inside somebody else's product.
We turn work down on this basis, so it is worth stating plainly. Custom development is the wrong answer in several common situations, and recognising yours here will save you a great deal of money.
If several of these describe your situation, the honest recommendation is to stay where you are and revisit in a year. That is the answer we give on calls more often than the alternative.
Companies that do build usually assume they need to replace the whole platform. They do not, and the attempt is the most common way these projects fail.
The workable shape is narrow. Build the technician side properly and build the minimum the office needs to see and correct what comes in. A full dispatch and scheduling console is effectively a second application, and it is often worth deferring until you know how the field side behaves in real use.
Scoping that first version is a discipline of its own. We work it backwards from the invoice, because the records that decide the invoice are the ones that cannot wait for version two. Everything else can.
What the framework will not speed up
Two things decide the calendar more than the technology, and they sit on the client side. The first is accounts and access: the store developer accounts and the credentials for the systems you want the app to talk to. In our projects the single largest source of slippage has been access arriving late, and setting up a store account is not a same day task.
The second is having one person who can decide. Field software touches operations, finance and the crews, so scope questions arrive constantly. A named owner keeps a project on schedule more reliably than any process we could impose.
Some requirements only appear once the app is running in the real environment, and no specification process finds them first. On our TimeFix project the work timer had to keep counting while the technician locked the screen or took a call from inside the app itself. That did not come from a requirements conversation. It came from real use.
This is why we ask clients to put their own team on the app in the field, during or after development rather than only at the end. Their crews find the things that were impossible to specify. Planning for that phase, instead of treating it as a defect period, is the difference between a launch and a long argument.
It is also why the commercial model matters. We work on a fixed price, with delivery closed by a signed acceptance protocol and a warranty on the software for larger contracts. Buyers in industrial and service sectors already know that language from purchasing equipment, and it makes the conversation about scope changes a great deal calmer.
Look for three things together: a billing decision a person has to make after the visit, a record your technicians keep outside the system, and data entered twice across two systems. One of those is a workaround worth fixing inside your current tool. Three of them means the operation no longer fits the product.
Not usually, and that is the wrong reason to build. A custom app carries its own ownership cost after launch. The case for building rests on work the packaged tool cannot do at all, such as coverage logic or offline job completion, not on licence arithmetic. We set out what moves the number on the field service cost page.
No, and we would advise against it. The common shape is a custom technician app that covers the work your platform handles badly, running alongside the systems that already work. Replacing scheduling and invoicing that function perfectly well adds cost and risk for no operational gain.
A narrow technician application is typically a matter of months rather than weeks, and a full system with an office side takes considerably longer. Offline work, integrations and payments each add time. The timeline guide breaks down where the weeks actually go.
That is a different starting point and it deserves an audit before anything else. In the cases we have inherited, the cause was usually that the supplier did not understand the operation. A useful early warning sign is a supplier who asks about technology before asking what the business problem is.
Yes, and often more strongly, because inspection work is equipment centred by nature and frequently happens where there is no signal. The same six signals apply, with the equipment history and offline items carrying more weight. We cover that case on the inspection app development page.
Written by
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Bring your six signals and we will tell you honestly whether this is a build, a fix inside your current platform, or something to revisit next year.
Book an intro call30 minutes, no preparation needed.