The hard part of a mobile app is rarely the screens.
The screens are the part everyone can see, so they get the attention. The difficulty sits underneath: two app stores with their own rules, phones that have been three OS versions behind since 2021, a network that vanishes in a lift or a field, and a review process that can hold a release for a week over a single permissions string.
None of that shows up in a design file. It shows up in month three, when the app is built and real people are holding it, and fixing it then costs far more than designing for it would have.
When the app is the product
In SaaS platform development the app is the thing people judge you by. They download it, rate it, and delete it if the first run confuses them. It has to feel fast and native, and earn a place on a home screen that is already full.
When the app runs the work
In business operations software the app is a tool your team depends on to get a job done, often somewhere with no signal and no patience for fiddling. It has to be quick and reliable, and built around the one workflow that matters rather than a menu of forty that do not.
01One codebase, both platforms
React Native and Expo, so iOS and Android come from a single codebase and a single team. You are not paying for the same feature twice, and the two apps do not drift apart over time. Native modules go in where a feature genuinely needs them.
02The native capabilities of the device
Camera, location, push notifications, biometrics, secure on-device storage. The native capabilities are what separate an app people keep from a website wrapped in an icon.
03Offline, and on networks that come and go
Plenty of the work happens where the signal does not reach. The app keeps going with nothing to connect to, then reconciles cleanly when the connection returns, without the person using it having to think about any of it.
04The backend behind the app
An app is only half a system. The other half is usually AWS Lambda and API Gateway, cloud-native and scaled to demand, with a deployment pipeline that makes a release boring. We build and run that half too.
05Into the stores, and kept current
Submission and review for both stores, including the parts of Apple's process that catch people out. Then over-the-air updates for the JavaScript layer and staged rollouts, so a fix does not wait a week on review.
The apps we shipped to real phones.
The usual shape is React Native through Expo on the device, with Node.js behind AWS Lambda and API Gateway, CloudFront in front and a CI/CD pipeline doing the releases. We are an AWS Select Tier Services Partner and run a Well-Architected review on every engagement, which is a large part of why the running cost does not surprise anyone once the users arrive.
GT World, for SRO Motorsports
A React Native app carrying live video, timing and team data to GT racing fans, replacing a Europe-only app with one that covers every series worldwide.
Offline-first survey app
Watts Group, on HS2
Surveyors record pre-condition surveys with no signal at all. The app works offline and reconciles when the connection comes back.
This all new app replaces the highly successful GT World Challenge Europe app delivering content from across the GT racing world. It's the complete GT World experience.
We prove the risky part on a real device before committing to the whole build.
- 01
Prototype
We build the flows that carry the most risk and put them on an actual phone early, often working alongside your design partner. A prototype you can hold answers questions a design file cannot: whether the gesture feels right, whether it is fast enough to trust.
- 02
Build
React Native through Expo, so one codebase produces both the iOS and the Android app rather than two teams building the same thing twice. Where a feature genuinely needs to reach into the platform, we write the native module for it. Where the job needs to work offline, we build for that from the first screen, not as a later patch.
- 03
Ship, and keep shipping
We handle submission to the App Store and Google Play, and the review that comes with them. After launch we stay: over-the-air updates for the JavaScript layer, an eye on the crash reports, and the OS upgrades that arrive every autumn whether you planned for them or not.
The things buyers ask us first.
Native or cross-platform?
We build cross-platform, in React Native, so one codebase serves both stores. When a feature genuinely needs a native module we write it. A fully native build in two separate languages is rarely worth the second codebase, and we will tell you on the rare occasion that it is.
Will it get into the App Store?
Yes. We handle submission and review for both the App Store and Google Play, including the permissions declarations and privacy details that tend to hold up a first submission.
Can you update it without a store release?
For the JavaScript layer, yes. Over-the-air updates go straight to devices, so a fix can ship in minutes. A store release is only needed when the native code itself changes.
Who will actually build it?
The two founders, and the trusted collaborators we bring in around them. No account manager between you and the people writing the code, and no junior learning on your project.