How to Choose a Mobile App Development Company Without Getting Burned

If a vendor gives you a number in the first call, before they've asked how many workflows your techs run offline, before they've asked what happens when two people edit the same job record at once, that number is a guess wearing a suit.

Estimates should come after discovery, not before. That's why the number holds. A mobile build for field crews or customer-facing use typically runs from $60k and takes 12–22 weeks, and where you land in that range depends on facts nobody can know before they've actually looked at your workflows. Before price, the person signing the cheque should get straight answers on three things: who owns what gets built, how the vendor arrives at the estimate, and what they'll admit they can't do — including whether you should build an app at all.

Who owns the code and the infrastructure — get this in writing first

Ask this before price, before timeline, before you've decided whether you like the portfolio. Vendor lock-in doesn't show up in the sales call. It shows up eighteen months later, when you want to switch vendors or bring the work in-house and find the repos live somewhere you can't reach and the infrastructure runs on an account you don't control.

The fix is contractual, not aspirational. You own the code outright from day one. The repos live in your organization. The infrastructure runs in your cloud account. Ask for this in writing before you sign, and be suspicious of any vendor who treats the question as unusual.

Watch how a vendor talks about payment, too. If anyone offers to take equity or defer payment for a better rate, that's not generosity. It muddies the relationship, and it has never once made the software better. Cash, milestones, clear scope. Anything else means someone's incentives point somewhere other than shipping what you asked for.

What a discovery week is actually supposed to lock down

Most vendors ask for a feature list and hand back a free estimate. That produces a number built on guesses. The order is backwards — you can't price scope you haven't defined.

A discovery week fixes the order. It's a flat, priced engagement, $4,800, credited back in full if you continue, that exists to answer what a feature list can't: which workflows have to survive without signal, what your existing systems look like underneath, where the data currently lives, who needs what level of access. It ends with three things: a written scope, an architecture sketch, and a fixed estimate. Not a range.

This is also where scope changes get handled honestly. If something changes mid-project, it gets priced before the work starts, not found on an invoice after.

What a mobile build costs and how long it takes

Mobile apps for field crews, technicians, or customers typically run from $60k and take 12–22 weeks, native iOS and Android or React Native depending on what the job needs.

What moves you inside that range is workflow count and complexity. An app that captures a signature and marks a job done is a different build than one that also tracks parts inventory, syncs barcode scans, and handles four crew roles with different permissions. Platform choice matters too. Building native for both iOS and Android costs more than a single cross-platform codebase, but buys tighter control over camera, GPS, and barcode hardware — which matters more for field work than for a customer-facing app.

Billing on a fixed-scope project runs on milestones: 30% at kickoff, then payment as each phase is accepted. That includes 30 days of post-launch fixes, so you're not paying separately to catch the bugs that only show up once real people are using the thing.

Offline-first isn't a checkbox

Offline-first data with conflict handling means every write happens locally first. The server is where things end up, not where things have to happen. That only works if someone decided, before writing a line of code, what happens when two technicians edit the same job while both are offline: does the last save win, does the app merge specific fields, or does it flag the conflict for a person to resolve by hand. A vendor who's actually built this will have an opinion on which rule applies where.

This is the hour your team keeps losing: the tech who finishes a job with no signal, assumes it's saved, and finds out at the shop that it never synced. Ask a vendor to walk you through exactly what happens in that scenario, start to finish. The answer tells you whether they've solved it or just described it.

The deliverables to ask about by name

Photo, signature, and barcode capture — can they show it working on the actual hardware your crews carry, not a simulator. App Store and Play submission — is that on them, account setup and review process included, or does it land in your lap at the end as a surprise. And if your crews use company-owned phones or tablets, ask about device management specifically: how new hires get provisioned, how a lost device gets locked, how the app gets pushed to fifty devices at once instead of one at a time. If a vendor can't speak to these by name, they haven't built one of these before. Worth knowing now, not in week fourteen.

Boring technology, on purpose

We build these apps in Swift, Kotlin, and React Native, not because they're exciting, but because they're not going anywhere. Novelty is a cost paid every year after launch, and it's paid by the client, not the vendor who talked you into it.

We're not choosing boring technology because we lack ideas. We're choosing it because you're the one who has to live with the app after we've moved to the next thing.

When the right answer is not to build an app

Sometimes the honest answer is: don't. If an off-the-shelf field service tool already does what you need — scheduling, dispatch, basic job tracking — for a tenth of what a custom build costs, building one from scratch is a bad use of your money, even if we're capable of doing it. We turn down projects a specialist would do better, or that an existing product already solves. You'll hear that in the first call, not the third, after a discovery fee has already changed hands.

Who stays on after kickoff, and what happens if you leave

A named lead stays from the scoping call through launch. Not a salesperson who disappears after signature, handing you off to whoever's free.

If you leave, whether the project ends or the ongoing care and improvement work stops, you get a full handover: an architecture walkthrough, runbooks, and two weeks of support. Ongoing work cancels with 30 days' notice. No long tail, no penalty. If a vendor won't commit to what handover looks like before you sign, that's your answer for what it'll look like after.