Powstania Warszawskiego 15
31-539 Kraków
Almost no field service app is the only system in the business. There is already an accounting package, a scheduling platform or an ERP holding the customer, the contract and the invoice. What the app is allowed to write into it, and in which direction, decides more about the build than any screen does.
A field service app integration is defined by three answers: which system holds the truth about a customer and a job, whether the other system exposes a documented API, and whether data moves one way or both. One way, out of the app and into the system that already bills, is the usual right answer for a first version. Two way sync between two systems that both allow edits is a different and much larger piece of work, and it is worth deferring until the field side is proven.
Three questions, answered before anyone estimates. Which system holds the truth, what that system exposes, and how many directions data has to travel. The number of fields is almost irrelevant next to those three.
These are questions for your own IT or your platform vendor, not for the app developer. Ask them before you ask anyone for a fixed price, because the answers move the number and the date more than the feature list does.
Nearly every field service project lands in one of three. Knowing which one you are is enough to tell whether integration is a line item or a phase of its own.
Jobs are created in the app or imported once. Completed work, time, parts, photos and sign off are pushed into accounting or the ERP so the invoice can go out. The other system never writes back.
Work orders are created in the existing platform and flow into the app, results flow back. Two directions, but each record is owned by one side. Common where dispatch and scheduling stay where they are.
Two systems holding the same records with both allowed to change them. Technically possible and occasionally necessary, usually in regulated or asset heavy operations with a mature ERP.
Build shape one, design the data so shape two is possible later. The business case for these projects is usually the gap between work finished and invoice sent, and shape one closes that gap on its own.
Integration is not a connector you buy. It is an agreement about which system is allowed to be wrong.
It still works, with a different mechanism and a different estimate. There are three routes, and which one applies is a question of what the vendor allows rather than what the developer prefers.
One more thing to check before deciding: whether your platform contract allows an external system to read or write your data at all. Per seat platforms sometimes price or restrict that. If it turns out the tool is fighting you, the wider question is covered in when you outgrow field service software.
It turns a live call into a delivery problem. Work is finished with no signal, arrives hours later, and must be accepted as valid even though the receiving system learned about it after the fact.
Crews in basements, tunnels and plant rooms are not an edge case in this work, so the queue between the app and the other system is a permanent part of the design, not a fallback. Every pushed event needs an identifier, so that a retry after a lost connection does not create a second job or a second invoice line.
Photos are their own case. They travel on a separate queue from form data, because a dozen site images on one bar of signal behave nothing like a text payload, and without compression the storage and transfer cost becomes a real part of running the system. The three different things people mean by the word are separated in what offline actually means in a mobile app.
Whatever the sync design, there has to be a way to correct a record by hand, from an admin panel or from the app itself. Two devices touching the same record stays rare in practice, but when it happens, somebody in the office has to be able to fix it without calling a developer.
The same applies to the boundary with the other system. If one push fails permanently, an operator needs to see that it failed and resend it. A silent queue is how a month of billing goes missing.
Only what the invoice needs. Four records decide whether a visit can be billed, and those are the four worth integrating first. Everything else can be added once the pipe is proven.
How these four are captured on site, and what deliberately waits for a later version, is worked through in field service app requirements. In inspection and compliance work there is usually a fifth, the report format a regulator expects, which is why inspection app development starts from the output rather than from the job.
A documented API adds one to three weeks per system. No API, or two way sync, moves it into its own phase and is the most common reason a field service project moves from the 10 to 14 week band into the 14 to 22 week band.
The variable is not the size of the payload, it is how many rounds of clarification the other side requires. Access to a sandbox, a contact who can answer questions about their own system, and permission to write are all things to secure in the kickoff week.
Where the rest of the weeks go is set out in how long a field service app takes.
For the commercial side, an integration is also the thing most likely to be quoted vaguely, because the vendor cannot see inside your platform either. Ask for it to be written as a named scope item with a named system, not as a general promise to connect.
The current bands by project shape sit on pricing, and what moves the number in this vertical specifically is on field service app development cost.
Five questions. If you can answer these, any competent supplier can price the work honestly, and the ones that cannot answer them are telling you something.
That last one is underrated. On projects that slip, the usual cause is not code but access: credentials, environments and approvals that sit with someone outside the project. How that gets handled when the development team is in another country is described in nearshore app development, and how scope and price are committed together in fixed price app development.
A shipped example of the field side that feeds all of this is the TimeFix case study, and the service page is field service app development.
Usually yes. A documented API is routine and adds one to three weeks per system. A platform with no interface needs a file exchange or a middle layer, which is a larger piece of work. The answer is knowable before you commit to anything, so it should be confirmed during scoping rather than assumed.
Whichever one bills. If invoices leave your accounting or ERP system, that system owns customers, sites and contracts, and the app references them. Keeping two authoritative copies of the same customer creates a reconciliation problem that grows with every job.
Rarely in version one. Most of the value is in completed work reaching billing the same day, which is one direction. Two way sync means agreeing precedence between two systems that can both be right, and it is worth building after the field side is proven rather than before.
It sits in a queue on the device, then syncs and is pushed onward when the connection returns. Each event carries an identifier so a retry cannot create a duplicate, photos travel on their own queue, and a failed push has to be visible to someone in the office who can resend it.
It is usually the option to avoid. You inherit the rules of a system you did not build without its validation, and an upgrade on their side can break the app quietly. A documented interface or a middle layer you control is more work upfront and far less risk afterwards.
Yes, if the data model is designed for it. That means stable identifiers, events rather than overwritten states, and no assumption that the app is the only system. Retrofitting an integration onto an app built as an island is where the expensive rewrites happen.
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.
Tell us which system runs your billing and scheduling today and we will tell you which of the three shapes your project is, what it does to the timeline, and what to confirm with your platform vendor first.
30 minutes, no preparation needed.