The hard parts are offline, release and review
Building screens for a phone is not difficult. What makes mobile expensive is everything around it: an unreliable network, a device you cannot log into, an app store that gates every fix behind a review, and users on a version you shipped fourteen months ago.
You might be here because
Situations we are brought in for
- Field staff lose work when they walk into a basement or a rural site.
- Shipping a fix takes a week because every release is done by hand.
- You maintain two native codebases and they have drifted apart in behaviour.
- Somebody has asked for an app and nobody has checked whether a web app would do.
What you get
Concrete deliverables, not a retainer with a hope attached
Platform recommendation
Cross-platform, native or a well-built web application, argued against your requirements — hardware access, performance profile, team composition and budget — rather than against a house preference. Often the answer is that you do not need an app.
Offline-first data layer
Local persistence, queued mutations and an explicit conflict-resolution policy, so a bad connection degrades the experience instead of destroying an hour of somebody’s work.
Release engineering
Automated builds, signing, staged rollouts, over-the-air updates where the stores permit them, and forced-upgrade handling for the users who never update.
Crash and performance monitoring
Symbolicated crash reporting, startup and interaction timings, and per-version dashboards — because on mobile you cannot reproduce a problem by looking at a server log.
How it works
Four phases, each with an exit you control
- 01
Qualify
We check whether an app is genuinely required. Push notifications, camera access and a home-screen icon are all available to web applications now; a store listing is a distribution decision, not a technical one.
- 02
Spike
The riskiest platform-specific capability is built first — background sync, Bluetooth, a payments SDK — because that is where cross-platform choices are proved or disproved.
- 03
Build
Two-week cycles with builds distributed to testers on real devices from the first cycle, not at the end.
- 04
Ship and keep shipping
Store submission, phased rollout and a release cadence your team can maintain without us, including the first update after launch, which is always needed.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for mobile apps. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- React Native
- Expo
- Swift
- Kotlin
- SQLite
- PostgreSQL
Where this usually starts
Build Cycle
Most common
Build Cycle
Getting a defined product or feature set shipped to production
A dedicated senior team working in two-week cycles against an agreed outcome. You see working software at the end of every cycle and can change direction between them.
- Typical duration
- From 6 weeks
- Commitment
- Rolling, cycle by cycle
Includes
- A senior team sized to the work
- Two-week cycles with a working demo at the end of each
- Direct access to the engineers building it — no account layer
- Your repositories, your CI, your review process
- Production readiness and handover built into the plan
You keep
- Working software in production
- Test suite and CI pipeline
- Architecture and operations documentation
- Handover sessions with your team
Fee agreed after scoping. No commitment to that conversation.
Common questions
React Native or fully native?
React Native for most applications whose value is in workflow and data rather than in device capability — one codebase, one team, faster iteration. Native when you are doing sustained work with the camera, audio, Bluetooth or graphics, or when the app is the product and every interaction detail matters. We have shipped both and will tell you which your requirements actually imply.
Do we need an app, or would a web app do?
A meaningful number of app projects would be better served by a well-built mobile web application: no store review, instant updates, no install friction, one codebase. You need a native app when you need reliable background execution, deep hardware access, or presence in the store for distribution reasons. That is a short conversation and worth having before the budget is committed.
Can you get us through App Store review?
Yes. Most rejections are predictable — account deletion, sign-in requirements, permission strings, subscription presentation, or an app the reviewer considers a repackaged website. We design against the current guidelines rather than discovering them during submission week.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
Legacy modernisation
Untangle the system nobody fully understands — without stopping the business.
AI & applied ML
Put language models into production without betting the product on a demo.
Custom software
For the process no product on the market actually fits — built once, properly.
SaaS development
Multi-tenancy, billing and onboarding — the unglamorous parts that decide whether it scales.
Web applications
Serious applications in the browser — dashboards, editors, real-time tools that stay fast with real data.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.