04Service
Mobile Applications
The app is the easy half. We build the half that has to still work in a year.
- Service
- 04 / 06
- Outcome
- iOS and Android on a backend built to hold
- Core stack
- React Native · TypeScript · Node.js
Shipping a mobile app to a store is a solved problem. Keeping one alive is not. Connectivity drops mid-action, two devices edit the same record, the OS deprecates an API, and the store rejects a build the week of launch.
We design for those from the beginning: what happens offline, how conflicts resolve, how sessions expire, how an old version behaves when the API moves on. The backend is built alongside the app rather than assumed.
Cross-platform or native is a decision we make with you based on what the app has to do, not on what we prefer to write. Most business applications are well served by one cross-platform codebase; some genuinely are not, and we will say which yours is.
Signs you need this
- Field staff need to work where there is no signal
- Your customers are on their phones and your product is not
- An existing app is unmaintained and nobody can build it any more
- Push notifications are the difference between use and abandonment
- The app works but the backend falls over when it gets busy
- Problem
- A mobile app is easy to ship and hard to keep — offline states, push, releases and backend load all arrive after launch.
- Solution
- Cross-platform or native applications built alongside the API and infrastructure that support them, with release and update paths planned from the start.
- Outcome
- An app that survives contact with real usage instead of one that needs rebuilding at the first scale problem.
/What the work includes
How the work actually runs.
Scope is agreed in writing before the build starts, and every stage produces something you can inspect.
- 01
Platform decision
Cross-platform or native, argued from the app's actual requirements — hardware access, performance profile, team and budget.
- 02
Offline and sync
What is available without a connection, how changes queue, and how conflicts resolve when two devices disagree.
- 03
Backend and authentication
The API, data model, sessions and permissions the app depends on, built to carry the load the app will create.
- 04
Release pipeline
Store accounts, signing, build automation and staged rollout, so shipping an update is routine rather than an event.
- 05
Post-launch
Crash reporting, usage analytics and a maintenance path for OS updates that arrive whether you planned for them or not.
Typical stack
- React Native
- TypeScript
- Node.js
- PostgreSQL
- Push APIs
- CI/CD
What you receive.
- iOS and Android applications
- Offline and sync behaviour
- Push notifications
- Backend APIs and auth
- Store release pipeline
Straight answers.
- Native or cross-platform?
- Cross-platform for most business applications — one codebase, two platforms, materially lower cost to maintain. Native when the app depends on heavy device capability or sustained high performance. We make the case either way rather than defaulting.
- Do you handle the App Store and Play Store?
- Yes, including account setup, signing, store listings, review submissions and the rejections that occasionally come back. The accounts are registered to you, not to us.
- What about an app we already have?
- We audit it first: what is salvageable, what is holding it back, and whether extending it is cheaper than replacing it. Sometimes the honest answer is that a rebuild costs less than another year of patches.
Other services
Need Mobile Applications? Tell us the problem.
The first conversation is about your operation, not our stack. If a smaller fix would do the job, we will say so before quoting a larger one.