Apps that hold up where the signal drops
You get an iOS and Android app your field team can use in a basement, on a tank farm, or on a shift floor. We stay on it after the store release.
Most mobile apps are tested on office wifi and used somewhere far worse. The people who need yours are standing next to a fuel tank, or starting a shift in a building with thick walls. So the questions that decide whether your app survives are boring ones. What happens to a half-finished form when the connection dies? Who gets paged when the store rejects a release? We answer those in week one, because retrofitting them later means rewriting the app.
The demo passes. The Tuesday shift does not
A mobile demo is a rehearsed run on good wifi. Real use is messier. A tech opens the app with one bar, fills in an inspection, and walks into a metal building. If nobody planned for that moment, the form is gone and the tech stops trusting the app by Thursday.
Nobody scopes the app stores either. Apple and Google both review releases, and both can reject one. A build with no owner after launch sits broken in the store while your team goes back to paper.
So we start with where your users actually stand, not with the screens.
What we have shipped
Counted, not estimated
22
systems in production
3
of them React Native apps: TankAware, Shift Link, ExtraaJe
5
permission tiers governing TankAware, from contractor to super admin
70%
less manual compliance checking at Shift Link
What we actually build
Real apps, running for named clients. Not capability nouns.
Apps for people holding a clipboard
TankAware replaced paper inspection logs across every petroleum tank Sutherland Excavating runs in Canada. The mobile side is React Native; IoT tank sensors feed the same platform. The operator reported 40% fewer manual errors.
Apps that decide who may work
Shift Link onboards UK agency workers, checks their documents against the government Right to Work API, then offers shifts only to the people who pass. Web in Next.js, mobile in React Native, one Supabase backend.
Apps staff open because they want to
ExtraaJe reads shift data from Planwork, turns it into points, and lets European staff spend them in a React Native app. HR runs the campaigns from a web dashboard, in Dutch and English.
Native Swift and Kotlin, when the hardware demands it
React Native is our default because most business apps do not need two codebases. We go native when an app leans on the camera, background location or a platform feature React Native does not reach cleanly. We tell you which one you need before you pay for either.
- ScopeFree call. Where do users stand?
- DecideReact Native or native. In writing.
- BuildOffline and sync first, screens after.
- ReleaseBoth stores. We handle review.
- RunCrash alerts, OS updates, store rules.
Most projects put Release last and treat it as a formality. Apple and Google both update their rules, and an app that ships once is not an app that stays installable.
What your app does with no connection
Offline is a data decision, not a feature toggle. Two people edit the same shift on two phones with no signal. When both reconnect, one of them is wrong, and your app has to know which.
We settle that before any screen gets designed. Which records live on the phone, and how long. What happens when two edits collide. What the user sees while work is queued. Get it wrong and the app looks fine while it quietly loses data.
- Records the user needs offline are chosen deliberately, not cached by accident.
- Queued work is visible, so nobody submits a form twice hoping it took.
- Conflicts have a rule you agreed to, not whichever write landed last.
- Photos and documents upload when signal returns, without blocking the app.
What we build on
Mobile
Backend
Run
Shipped integrations
Mobile builds running now
“TankAware has revolutionized how we manage petroleum sites. The real-time data and automation have exceeded expectations.”
Blake Sutherland · President, Sutherland Excavating Ltd.
The usual mobile project against ours
Both put an app in the store. They part company in month three.
| Criterion | The usual approach | How we build |
|---|---|---|
| Where it is tested | Office wifi, on the newest phone in the room. | The conditions your users work in, including no signal at all. |
| Offline behaviour | Added later, once a user loses a form. | Decided in week one. Conflicts have a rule you agreed to. |
| Native or cross-platform | Whatever the shop already builds in. | We say which one your app needs, and why, before you commit. |
| Store releases | Your team discovers the review process on launch day. | We submit, handle rejections, and keep the app installable. |
| After the OS update | Reported by a customer whose app now crashes. | Crash reporting we watch, under an agreed service level. |
01Should we build one React Native app or separate iOS and Android apps?
React Native fits most business apps, because one codebase serves both stores and the work does not double. TankAware, Shift Link and ExtraaJe all run on it. Go native in Swift or Kotlin when the app leans hard on the camera, on background location, or on a platform feature React Native reaches badly. We give you the answer in the scoping call, before you have spent anything.
02Will the app work with no internet connection?
Yes, when we design for it from the start, which is the only time it is affordable. That means picking which records live on the phone and showing the user what is queued. It also means agreeing a rule for two people editing the same record offline. Bolting offline support onto a finished app usually means rebuilding the data layer.
03Who submits the app to the App Store and Google Play?
We do, under your developer accounts, so you own the listings and the signing keys. Both stores review submissions and both reject builds for reasons that change over time. Handling that is part of the engagement rather than a surprise your team meets on launch day.
04What happens when Apple or Google releases a new OS version?
Your app gets tested against it and updated, under an agreed service level or by your own team after a documented handover. You pick which at the start. An unmaintained app does not fail on release day. It fails quietly, one OS version later, and your users just stop opening it.
05Can you take over a mobile app another team built?
Often, yes, and that is where the paid two-week diagnostic applies. We read the codebase, run the app in the conditions it is actually used in, and report what is fixable against what should be replaced. Scoping calls for a new build are free, because there is no codebase to read yet.
06Does the app need its own backend, or can it use what we already run?
It can use what you already run, through your existing APIs, which is usually cheaper than any migration. Shift Link's app calls the same Supabase backend the web platform uses, plus the UK government's Right to Work API. We only propose a new backend when the old one cannot serve a phone safely.
07What does it cost to build a mobile app?
Cost is driven by the number of platforms, how much of the app must work offline, and how many systems it has to talk to. Quoting a range before seeing the workflow is guessing, and the guess is always wrong in the same direction. The scoping call is free, and you get one fixed price before the build starts.
08We are a startup with no mobile team. Is this only for enterprises?
Both, and the shape differs. A startup usually wants one workflow in users' hands and evidence it holds up, so we ship narrow and instrument it. An enterprise wants role-based access, audit trails and integration with systems already running, which is what TankAware needed across five permission tiers. The offline and release discipline is identical.
Related
- Web app development →The product your customers log into.
- Custom software development →The build itself, web and mobile together.
- Build vs buy software →When an off-the-shelf app is the right answer.
- Hire React developers →Engineers who have shipped React Native to both stores.
- TankAware →Paper inspection logs replaced across a petroleum operator.
