Field service software
How to Choose a Field Service App Development Company: 8 Questions to Ask Before You Sign
Most advice on how to choose a field service app development company is generic agency advice with a new title. Field work breaks apps in specific places: no signal, photos that never arrive, records the office cannot fix. These eight questions test whether a company has built for those places before.
Short answer
To choose a field service app development company, ask questions only a team with field experience can answer well: what the app does with no signal, how photos reach the office, how the office corrects a wrong record, how the app connects to your accounting or ERP, what version one covers, how your technicians test it before launch, and who owns the code and accounts. Ask for one requirement from a past field project that was not in the specification. A team that has shipped field apps will have one ready.
Key takeaways for operations and service leaders
- Portfolios do not separate field apps from office apps. The answers to these questions do, because they come from projects, not from sales material, and they show whether a custom field service app was built for crews or for a demo.
- Offline is the first question, not the last. A company that treats it as a feature to add later will build an app your crews stop using in basements.
- The office side decides adoption as much as the phone side. If a wrong record needs a developer to fix, the spreadsheet comes back within weeks.
- A good answer names a trade off. Be careful with answers that promise everything works everywhere with no decisions from you.
Why generic agency checklists miss field work
Most checklists for choosing a developer ask about portfolio, process, communication and price. Those matter, but they would select the same company for a booking site and for an app used by forty technicians in plant rooms. Field apps fail for reasons an office project never meets, so the evaluation has to go where those reasons are.
What an office app assumes
- A stable connection on every screen
- One user at a desk, one record at a time
- Errors fixed by refreshing the page
- Testing in a browser before release
What a field app has to survive
- Hours without signal, then a burst of uploads
- The same job touched by a technician and the office
- Gloves, glare, locked screens and phone calls mid job
- Testing on real jobs, not only in a simulator
The questions to ask a field service app developer, listed below, follow that second column. Each one comes with what a useful answer sounds like and where to probe further. They work for any company you talk to, including us, and they assume you are hiring a team for an end to end field service app development project: mobile app, office panel and integrations from one team.
How to choose a field service app development company: eight questions
What did you learn on a past field project that was not in the specification?
This is the fastest filter you have. Any team can describe offline sync in a meeting. Only a team that has watched technicians use an app on real jobs can name the thing that went wrong first.
A specific requirement, the project it came from, and what changed in the app because of it. Ideally something small and physical: a timer, a screen, a habit of the crew.
Answers about process, agile ceremonies or client communication. Those are real, but they are not field experience.
What exactly happens to a job when the technician has no signal?
Offline is three different requirements under one word: reading jobs that were already downloaded, creating and editing work without signal, and resolving what happens when the office changed the same job in the meantime. Each costs a different amount, and the company should tell you which ones your crews need.
Which screens work offline, that records are saved on the phone first, that each record shows whether it is saved or sent, and a rule for conflicts agreed with you before the build. Our guide to offline mobile apps goes deeper, and Android's own guidance on building an offline first app describes the same pattern.
"The app caches data" with no detail on editing, or offline listed as an extra phase after launch.
How do photos get from a basement to the office?
Photos are where field apps quietly fail. A dozen high resolution images sent on one bar of signal can stop halfway and leave a finished job looking incomplete in the office. How a company answers this tells you whether they have dealt with real uploads.
Photos travel in their own queue, separate from hours and forms, are compressed on the device, and are attached to the right job even if they arrive hours later.
Photos sent together with the form in one request, or no plan for what the office sees while uploads are waiting.
When a record is wrong, how does the office fix it?
Wrong hours, a job closed against the wrong customer, a duplicate visit. These happen in the first week of real use. If the only way to fix them is a request to the developers, the office goes back to its spreadsheet and the app loses its place as the source of truth.
A web panel where the office can review, approve and correct any record, with a history of who changed what. Included in version one, not left for later.
A proposal that covers only the mobile app, or an admin area described as "basic" with no list of what it can do.
How will the app connect to the accounting or ERP system we already use?
The point of a field app is that work recorded on site reaches invoicing without being typed again. That only happens if the integration is scoped as carefully as the screens. Our guide to field service app integration covers the common patterns.
Questions back to you: which system, which version, whether it has an API, who holds the credentials, and what happens when the other system is down. Then a written decision on what syncs in which direction.
"We can integrate with anything" before anyone has looked at your system.
What would you put in version one, and what would you leave out?
A company that agrees to build your whole wish list in one release is either padding the price or planning to cut quietly later. A good partner pushes back and proposes one complete job flow first, from the office creating a job to the invoice.
A short version one built around your most common job type, a written list of what is excluded, and a reason for each exclusion. Our guide to version one of a field service app shows how that sorting works.
A proposal with no exclusions at all, or one that copies your feature list back to you with a price under it.
When do our own technicians get to use it, and on what jobs?
The requirements that matter most surface when crews use the app on real work. If the first time your technicians see the app is launch day, those requirements arrive as complaints instead of as changes during the build.
A working build every one or two weeks that a few of your technicians install and use on real jobs, with a simple way to report what does not fit. More in our guide to field service app adoption.
Demos only, screen recordings instead of installable builds, or testing limited to the office.
Who owns the code, the accounts and the data, and what happens after launch?
A field app becomes part of how the business runs. You need to be able to keep it running if you change supplier, and you need to know what is fixed at the company's cost when something inside the agreed scope does not work.
Code, store accounts, hosting and data in your company's name from the start, a written acceptance against the scope, and a stated warranty period. See how acceptance works in a fixed price project.
Store accounts or servers registered to the company, or "support" offered only as a monthly retainer with no guarantee on the original scope.
The right field service partner asks you more questions in the first call than you ask them.
How we answer the first question
It would be unfair to ask these questions without answering one ourselves. Here is the field lesson we bring up most often, with the projects behind it.
The timer that had to survive a locked screen
On TimeFix, a time and job tracking app for technicians, the work timer had to keep counting when a technician locked the screen or took a phone call from inside the app. It was in no document. It came from crews using builds on real jobs.
The same project taught us to treat side notes as missing features. Before the app covered a particular case, technicians started writing it in the notes app on their phones, and the office data drifted from reality.
On Liniowiec, an offline navigation app, everything worked in the simulator. Real use on the water showed connection drops and wrong positions, and fixing those was the actual work.
If your crews work in heating and cooling, the same questions apply to custom HVAC software development, with service agreements and equipment history added to the list.
The eight questions in one place
Copy these into your notes for the first call with each field service app developer. The answers are easier to compare when every company gets the same questions in the same order.
- What did you learn on a past field project that was not in the specification?
- What exactly happens to a job when the technician has no signal?
- How do photos get from a basement to the office?
- When a record is wrong, how does the office fix it?
- How will the app connect to the accounting or ERP system we already use?
- What would you put in version one, and what would you leave out?
- When do our own technicians get to use it, and on what jobs?
- Who owns the code, the accounts and the data, and what happens after launch?
How to choose a field service app development company once the proposals arrive
Price and timeline from a field service app developer only mean something next to the scope they describe. Put the proposals side by side and check that each one covers the same job flow, the same offline behaviour, the office panel and the integration. A lower number that leaves out the panel or treats offline as a later phase is a different product, not a better deal.
Our guides on comparing app development quotes and on building versus buying field service software help with that step. Realistic durations are covered in our field service app development timeline.
About the source
Who is answering this?
- Company
- Apps Value, mobile app development agency
- Location
- Kraków, Poland
- Markets served
- United States, Western Europe, Nordics
- Experience
- 6 years, 19+ projects delivered, 13+ positive client reviews
- Technologies
- Flutter, React Native, NestJS, Supabase, PostgreSQL, AWS, Google Cloud
- Engagement models
- Fixed price contracts and dedicated development teams
- Field apps we have shipped
- TimeFix, Liniowiec
FAQ
How to choose a field service app development company?
Ask questions that only field experience answers well: what the app does with no signal, how photos reach the office, how the office corrects records, how the app connects to your accounting or ERP, what version one covers, when your technicians test it, and who owns the code and accounts. Then compare proposals that describe the same scope.
What should a field service app development company include in a proposal?
The mobile app, an office panel for review and correction, offline behaviour defined screen by screen, the integration with your existing systems, a written list of exclusions, a timeline with its conditions, and the terms of acceptance and warranty.
Should the company have built an app for our exact trade?
It helps, but it matters less than field experience in general. Offline work, photo uploads, crew adoption and office corrections are the same problems across HVAC, electrical, plumbing and inspection work. Trade specifics are learned in discovery; field experience is not.
How long does it take to build a custom field service app?
A first version built around one job flow usually takes 8 to 12 weeks. Offline editing, several integrations or many job types extend that. A company should tie every timeline to a written scope and to how fast decisions and access arrive from your side.
How much does it cost to hire a field service app development company?
It depends on the job types, the offline requirements and the integrations rather than on the number of screens. We agree one fixed price for a written scope before development starts; current price bands are on our pricing page.
Related guides
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.
Put the eight questions to us
Bring your list and one job from your business, from the first call to the invoice. You will get our answers to every question and a view of what a first version of your app would cover.