Software
Mobile applications
Mobile software for people who are not sitting at a desk — field teams, floor staff, drivers, and customers on the move.
What this is
The work, described plainly
The question worth asking first is whether you need an app at all. A well-built web application installs to a home screen, works offline, and skips both app stores. For a lot of internal tools that is the better answer and we will say so.
When you do need native — camera access, background location, push at scale, or a store presence — we build cross-platform so one codebase serves both platforms, and drop to native modules only where the platform genuinely differs.
Field software has to assume the network is not there. Offline-first storage and conflict resolution are design decisions made at the start, not features added when the complaints arrive.
What you get
What is actually handed over
Concrete deliverables, not phases on a timeline.
Cross-platform application
One codebase for iOS and Android, with native modules where the platforms actually diverge.
Offline-first data
Local storage and sync that behaves sensibly when two people edited the same record on different networks.
Store submission
Builds, signing, listings, and review responses handled through to release.
Update pipeline
A route to shipping fixes that does not wait on store review for every change.
Is this you
Signals this is the right fit
- Your users are on their feet, not at a desk.
- You need the camera, GPS, or reliable push.
- Work happens where the signal does not.
- You need a presence in the app stores.
Typical stack
Chosen per project against your constraints, not applied by default. This is what the work usually involves.
- React Native and Expo
- TypeScript
- SQLite for local storage
- Push notifications
- Fastlane
FAQ
Questions people actually ask
Do we need an app or a mobile website?
Often a website. If you do not need the camera, background location, or a store listing, an installable web app is cheaper to build, faster to update, and has no review process. We will tell you which one your case needs.
One codebase or two?
One, in most cases. Two native codebases doubles the maintenance for a difference your users will not notice, unless you are pushing hard against platform capabilities.
What does the store process involve?
Developer accounts, signing, listings, privacy declarations, and a review that can reject on the first attempt. We handle it, and we plan for a rejection round rather than assuming a clean pass.
Start here
Tell us what is slow, manual, or breaking.
Answer a few questions and get a written brief back — scope, proposed architecture, and what it would take to build.