Most business apps are not the next social network — they're the job the crew currently does on paper, a phone call, and a photo texted to the office. We build those for iOS and Android from one codebase, make them work where there's no signal, and put them in the stores under accounts you own.
Field crews, warehouses, and customers — the three places where the work happens away from a desk and the paperwork catches up later.
The clipboard that turns into a record before the tech leaves the site.
Scanning, proof of delivery, and stock counts on hardware that gets dropped.
The app your customers install — so it has to look the part.
For staff, not the public — distributed without a public store listing.
This is the first question, and getting it wrong is expensive in both directions. An app you didn't need costs you two store listings to maintain forever; a website where you needed an app leaves your crew fighting it. The honest test is short.
If the answer is the second list, we'll say so and build you a responsive Web app instead. We'd rather lose the app-sized invoice than sell you an app store presence you have to feed.
Flutter is our default: the iPhone and Android versions are built from the same code, which costs roughly half of writing the app twice and keeps the two from drifting apart later.
Swift or Kotlin when an app leans hard on platform-specific behavior. That's a real decision we make with you, not a default we charge for.
Local storage, a sync queue, and conflict handling from the first version — not a patch after the first week of complaints from the field.
Apple and Google developer accounts in your business's name, signing keys handed over, and the source in your repository.
Free, 30 minutes. What the crew does now, where the signal drops, and whether an app is genuinely the right answer.
Clickable screens on a real phone before the build starts, with the app and the server side priced separately.
TestFlight and Play internal testing from early on, so your people are using it long before anyone outside sees it.
Listing, screenshots, privacy declarations, and review responses handled — then the keys, the accounts, and the code are yours.
An app that can't reach your existing systems just moves the re-typing somewhere else. The server side — the API, the sync, and the integration into the ERP, WMS, accounting, or scheduling system you already run — gets built as part of the same engagement, by the same person.
The honest range is wide, so here is what moves it: a focused first version of a single workflow — log in, do the thing, sync — is a few weeks of work. Offline sync, hardware scanners, payments, and a back office to administer it each add real time. We quote after a free scoping call, and the quote separates the app from the server side so you can see what each part costs.
Design and a working build come first, then store review. Apple's review is typically a day or two once the listing is complete, Google's similar, and both can add a round if something in the listing needs changing. We budget for one rejection because first submissions often get one, and we write the listing and handle the responses rather than passing that back to you.
No. Most of our mobile work is Flutter, which builds both from one codebase — roughly half the cost of writing the app twice, and the two versions cannot drift apart afterwards because there is only one of them. Fully native in Swift or Kotlin is still the right answer for a few apps, and we will say so when it is.
You do. The developer accounts are registered to your business, with your legal entity on the listing, and we work inside them. An app published under a contractor's account is a problem you inherit later — you cannot transfer users, reviews, or the listing without their cooperation. We set it up the other way around from the start.
If your crews work in basements, warehouses, yards, or rural routes, offline is a requirement and we build it in from the start rather than bolting it on. The app keeps working against local storage, queues what changed, and syncs when the connection returns — with conflict handling for the case where two people edited the same job.
Yes, more than websites do. Apple and Google both raise their minimum requirements every year, and an app that is not rebuilt against them eventually stops being accepted for updates. A small retainer covers the OS and store compliance updates, crash monitoring, and small changes. You can also take it in-house — the code, the signing keys, and the store accounts are yours.
That is usually the whole point. An app that does not reach your ERP, WMS, accounting, or scheduling system is just another place data goes to be re-typed. Integration is what we do on the server side anyway, so the app and the connection to your existing systems get built as one job.
Common, and fixable more often than not. We take over the codebase, get it building again, move the store listings into accounts you control where that is possible, and tell you honestly whether the existing code is worth continuing or whether a rebuild costs less than the repairs.
Paper, phone calls, and photos in a group chat is a perfectly good starting spec. We'll tell you what an app would take — or that you don't need one.
