Mobile App Development Services
A mobile app is the easiest kind of software to ship badly and the hardest to fix once it is sitting in the stores. We build iOS and Android products that pass review, launch on the date you announced, and keep working through the OS releases that arrive every autumn.
Mobile App Development done properly.
Three shapes of mobile product. They share a codebase strategy and almost nothing else.
- Consumer Mobile Apps
Products aimed at the public, where the time between install and first useful moment decides whether the app survives its first week. Onboarding, push, deep links, in-app purchase and store submission are designed as part of the build, not discovered once the features are finished.
- B2B Mobile Apps
Apps your customers use to transact with you — ordering, tracking, account management, field service. The hard part is rarely the app; it is the systems behind it, so your existing platforms are treated as a first-class input to the design rather than an integration to sort out later.
- Enterprise Mobile Apps
Internal tools for people who are standing up, wearing gloves or out of signal. Offline-first storage, sensible conflict resolution when a device reconnects, role-based access and managed distribution to company devices instead of a public store listing.
Where this usually goes wrong.
Named up front, because avoiding them is most of the value.
- Designed in a desktop browser
Layouts signed off in a maximised window come apart on a 375-point screen with the keyboard open. We design to the smallest supported device first and treat the wide layout as the derivative.
- Native or cross-platform decided too late
Teams commit to two native codebases before anyone has asked whether the product needs them. That call belongs at the start, with the roadmap on the table, and it belongs in writing.
- Store review treated as a formality
Rejections over account deletion, tracking permission, sign-in options and payment rules are predictable and preventable. Compliance goes in the plan, not into the week before launch.
- No budget for next September
iOS and Android each break something every year. An app with no maintenance line item has an expiry date, whether or not anyone has written it down.
The engagement, phase by phase.
Every phase is run by senior engineers and ends in something you can see.
Mobile strategy
What the app is for, who has to adopt it, and which native capability actually justifies an app instead of a responsive site.
Platform decision
Native, cross-platform or web, argued against your roadmap and budget rather than our preference — and recorded with the trade-off attached.
Flows and design
Screen-by-screen flows and a design system sized for real devices, so the build starts from settled decisions instead of open questions.
Build in sprints
Whole features each sprint, on TestFlight and an internal Android track from the first one, so you are using the app while it is still being written.
Test on real hardware
Automated regression plus manual passes across the device and OS matrix your users actually carry, including the older phones that are easy to forget.
Launch and keep alive
Listings, review compliance, staged rollout and crash monitoring — then the annual OS cycle that decides how long the app lasts.
Shipped, and still running today.
Three mobile products in production, each solving a different distribution problem.
- eLaundry →
Native iOS and Android apps for both customers and operators, with the routing, dispatch and billing dashboard behind them.
- Caterday →
Swift and Java mobile companions to a marketplace web app, sharing one Node.js backend and GPS lookup for nearby suppliers.
- MealDaay →
One app serving customers and kitchen owners through role-specific experiences, with GPS routing through to delivery.
What we build it with.
Chosen per project, and for what your team can maintain afterwards.
Questions we get asked.
Should we build native or cross-platform?
It depends how much of the product is genuinely platform-specific. Heavy camera, Bluetooth, background location or platform-native UI work usually pays for native. A form-and-list product that has to reach both stores quickly usually does not. We make the call with your roadmap in front of us and write down the trade-off, because reversing it later is expensive. Our post on native versus cross-platform apps goes through the reasoning in more depth.
Do you publish the app to the App Store and Google Play?
Yes — submission, listing copy, screenshots, privacy declarations and responses to reviewers are part of delivery. We work inside your developer accounts rather than ours, which means the app, its signing identity and its reviews stay yours if you ever change vendor.
Who owns the code?
You do. Source, repositories, build pipelines and infrastructure accounts are yours and are handed over at the end of the engagement. We do not keep client products parked in our own accounts.
Can you take over an app somebody else built?
Often, and we will say plainly when the answer is no. It starts with an assessment of the codebase, the build pipeline and the store accounts, after which you get a written view of what is worth keeping and what is cheaper to replace.
How much does a mobile app cost?
Too much rides on scope for a number here to be honest. Roles, integrations, offline behaviour and how much design already exists move the figure far more than the choice of platform does. Our consultation page sets out the six factors that drive it, and a call turns them into a range for your requirements.
What happens after launch?
OS releases, dependency updates, crash triage and store policy changes carry on regardless. Either we keep a maintenance engagement running, or you take over an app documented well enough for your own team to maintain. Budgeting nothing is the one option that reliably fails.
Further reading.
What we have written about mobile app development and the decisions around it.
- Choosing the Right Approach for Mobile App Development →
Native or cross-platform? A practical comparison of cost, performance, hiring and long-term maintenance to help you pick the right approach.
- Mobile-first design: why and how →
Why mobile-first design matters and how to do it properly, including the team conversations that need to happen before a single screen is sketched.
- 9 best practices for mobile-friendly websites →
Nine concrete checks every product team should run before declaring a site mobile-ready — from tap targets and viewport to real-device testing.
Other services.
- Web Application Development →
Custom platforms, portals and SaaS — including replacing a legacy system while the business running on it stays up.
- Agentic Software Development →
Senior engineers directing autonomous agents that plan, write and test in parallel — with a named human accountable for every release.
- Salesforce Implementation →
Sales Cloud, Service Cloud and marketing automation configured around how your business really sells — with adoption as the deliverable.