App development
that survives week two.
iOS, Android and cross-platform apps shipped by a senior team that stays through the store review.
- — Your mobile experience is a wrapped website and users can tell
- — Releases are manual, rare and stressful
- — You have no reliable picture of retention after day seven
The work should
change the numbers.
The hard part of an app is not the first build. It is the second release: the migration, the version skew, the person still running the launch build eight months later, the review rejection two days before a campaign.
We build apps with that reality in view. Offline behaviour, error states, analytics and release tooling are treated as features rather than polish, because they are what separates an app people keep from one they delete after a fortnight.
Most engagements are cross-platform with React Native, which gives one codebase and near-native feel. We recommend fully native when the product depends on hardware, background processing or platform features that deserve first-class treatment.
What the engagement
actually contains.
Product definition
The smallest release that proves the idea, with everything else parked on a visible roadmap.
Platform architecture
Navigation, state, offline caching and API contracts designed before feature work starts.
Native integration work
Push notifications, biometrics, camera, location, payments and deep links wired properly per platform.
Release engineering
CI/CD, signing, staged rollouts, over-the-air updates and crash reporting from the first internal build.
Store submission
Listings, screenshots, privacy declarations and review responses handled by people who have done it before.
Post-launch instrumentation
Funnels, retention cohorts and crash-free-session tracking so the next sprint is informed.
- iOS and Android applications in the stores
- Source code and CI/CD pipeline
- Design system and component library
- API contracts and documentation
- Crash reporting and analytics dashboards
- Release runbook and store assets
- Your mobile experience is a wrapped website and users can tell
- Releases are manual, rare and stressful
- You have no reliable picture of retention after day seven
- An agency built version one and disappeared
What usually went wrong
before we were called.
- 01Treating offline, empty and error states as polish to add later
- 02Requesting notification and location permissions on first launch
- 03Manual release processes that make shipping a fortnightly event
- 04Adding analytics after launch, losing the most instructive month
- Day-7 and day-30 retention
- Crash-free session rate
- Completion rate on the core job
- Release frequency and rollback time
10–16 weeks to a first store release
What week one
actually looks like.
Scope reduced to the smallest release that proves the idea, with the rest on a visible roadmap. Store accounts, signing and a CI pipeline are set up before feature work starts.
- Apple and Google developer accounts
- Brand assets and store copy input
- API access or a backend owner
- Test devices or a device budget
- App store optimisation campaigns
- Paid user acquisition
- Ongoing customer support
- Developer account fees
Scope boundaries stated up front rather than discovered in a change request.
Four stages, visible throughout.
Model
The domain, data and permissions written down before any interface exists, because the schema outlives every screen above it.
Prototype
Flows and states tested as a clickable prototype, so the expensive disagreements happen in Figma rather than in code.
Ship in slices
One workflow at a time, in production, with tests and observability included in the definition of done.
Operate
Release tooling, monitoring and a documented handover so your team can run and extend what we built.
App development, answered.
React Native suits most business apps: one codebase, shared logic with your web product, and performance that users cannot distinguish in normal use. Go native when the app leans hard on hardware, background processing, complex gestures or platform-specific frameworks — a fitness tracker or a camera product, for instance.
Budget for meaningful ongoing work rather than nothing. Two OS releases a year, dependency and SDK updates, store policy changes and defect fixes are unavoidable. A retainer sized around one to two engineering days a month keeps a mid-sized app healthy.
Yes. We start with a code and architecture audit, get a build running in our environment, and give you a written assessment of what to keep, refactor or replace before committing to a roadmap.
We prepare the submission, write the privacy and data declarations, and handle reviewer correspondence. Most rejections are avoidable and come from metadata, account deletion requirements or unclear subscription terms rather than the code.
UI/UX design
Product-focused design: flows, states and interfaces judged on whether the job gets done.
SaaS & custom software
Product engineering for the system your business runs on and no vendor sells off the shelf.
API & third-party integrations
CRMs, ERPs, payments and internal tools connected so the data stops being re-typed by people.
QA & testing
Manual and automated coverage that finds the failure before your customers volunteer to.
Make app development useful.
Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.