Mobile app development
Our mobile work runs on construction sites, in vehicle bays and in plant rooms. It holds up with no signal, reads values off test equipment over Bluetooth, and produces a document somebody has to sign.
Book a 30-minute scoping call See the field apps
We are not the right team for a consumer social app. We will say so early.
| No signal for four hours Records queue on device | Handled |
|---|---|
| Two engineers, same job Conflict rules agreed with you | Handled |
| Reading from an instrument Bluetooth or vendor SDK | Handled |
| Battery through a full shift Sync batched, not chatty | Handled |
| Phone dies mid form Draft restored on reopen | Handled |
Where we fit
Both are called mobile development. They fail for completely different reasons, and are built by teams with different instincts.
Go elsewhere when
Consumer studios do this better than we do, and we will say so.
Come to us when
This is where our apps live. Every build below runs in the field.
Plain definitions
Both sound like detail. Both decide whether the app gets used after the first week on site.
It is an app built for someone doing a job away from a desk, usually against a defined procedure, usually producing a record somebody is accountable for. Jobs, inspections, readings, certificates.
The design constraints come from the environment rather than from the feature list. One hand free, gloves on, bad light, a phone that has to last a shift, and a supervisor who needs the result before the engineer gets back.
Offline tolerant means the app warns you and stops. Offline first means the app assumes there is no network, writes everything locally, and treats a connection as an opportunity to sync.
The hard part is not storage. It is deciding what happens when two engineers edit the same record from two devices, and that rule has to come from how your team works rather than from us. We agree it before we build it.
What we build
What people ask us for
Our work clusters here. If your project is none of these, we will say so on the first call.
Our work
Case study, United Kingdom
Hydrajaws makes portable pull testers. Their old app was poorly documented, they did not control the code, and the interface was holding back sales. We rebuilt it as a free tier and a premium tier from one codebase, put user management behind Azure AD B2C, and integrated the KTC SDK so torque and pull readings land in the record as measured.
Case study, automotive
Verify Auto needed an automotive safety compliance app where the interface had to match the brand as closely as the logic had to match the standard. We built it modular for scaling, integrated automotive APIs, and validated the design through prototypes with their stakeholders before writing production code.
How the work runs
Week 1
Where it is used, which handsets, which instruments, and what happens with no signal. Instrument models get checked before anything is promised.
Week 2 to 4
Screens designed for one hand and poor light, tested as a prototype with the people who will use it.
Week 5 to 12
A real crew uses it on real jobs while we are still building. Demo every two weeks.
Release
Submission, review cycles, and a rollout plan that does not strand engineers mid shift.
Technology and integration
Chosen by what the hardware needs and what your team can maintain, not by preference.
Who does the work
Field apps fail in ways that only show up on a roof or in a plant room. The engineers who build ours have spent enough time on instrument integration and offline sync to know where those failures hide.
You interview whoever we put forward. Ask them what happens when two engineers submit the same job from two devices, and judge the answer.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Cross-platform unless something forces native. We have shipped Xamarin and React Native. The deciding factors are usually hardware access and what your team can maintain, not raw performance.
If the device exposes a Bluetooth profile or a vendor SDK, yes. Send model numbers and we check each one before you commit.
Everything captures locally and syncs later. We agree the conflict rules with you, because what should happen when two people edit the same record depends on how your team works.
Yes, including internal distribution where the app is only for your own staff.
Yes. PDF generated at sign-off in your layout, available before the engineer has left site.
Your company, entirely. We hand over repositories and documentation on request.
A single-purpose app with one integration is usually 10 to 14 weeks. Add instrument integration, certificates and a supervisor portal and it runs longer. Instrument work moves the number most, which is why we check your device models in week one. What you pay depends on the engagement model above, and you get a figure after the scoping call.
Usually yes, if the device runs a current Android or iOS build. Rugged handsets from Zebra, Honeywell and similar makers are ordinary Android underneath, though hardware scanner buttons and any vendor-specific SDK need checking per model. Send the models with the enquiry.
Through the store or through your mobile device management, depending on whether the app is public or staff only. We plan the rollout so an update never strands somebody mid shift, which usually means the old version stays valid until the job in progress is submitted.
Site, bay, plant room or roof. What the environment demands decides most of the build, and it is the first thing we ask about.
