An app that only works on office Wi-Fi
It looked fine in the demo. Then your field staff or customers used it in a basement, a lift or a rural lane, and the screen spun forever or their work quietly vanished.
Build a product
Mobile app development, built for one thumb and patchy signal.
iOS and Android apps built with Flutter from one codebase, and native Swift where it matters. Designed around how people really use their phones, with working software to try every two weeks.
Sound familiar?
The problems this solves.
Two apps drifting apart
The iOS and Android versions were built separately. Features reach one long before the other, every bug is fixed twice, and nobody is sure which version is right.
Stuck at the store gate
The app is built but keeps bouncing back from review, or nobody on the team knows how to sign a build, fill in the privacy details and ship an update without breaking something.
Downloads, then silence
People install the app, open it once and drift away. Nothing tells you where they give up, and the only notifications they get are ones they switch off.
What you get
Concrete things, not adjectives.
An honest platform decision
Flutter, native Swift or a mix — chosen in discovery against the features you need and the budget you have. Sometimes the honest answer is a mobile website, and we will say so.
Screens designed for thumbs
Flows and a clickable prototype in Figma, tried at real phone size: one-handed reach, small screens and large text settings, plus the loading and offline states a slow connection needs.
One codebase, native where it counts
iOS and Android built together from one Flutter codebase, so features reach both at once. Where a feature needs closer access to the device than Flutter offers, that small part is written natively — in Swift on iOS — and plugged into the shared code.
Built for real-world signal
Data saved on the phone and synced when the signal returns, clear messages when something is still waiting to send, and testing on slow and dropped connections.
Notifications and analytics with a purpose
Push notifications people can control and actually want, plus analytics on the few moments that matter — where people sign up, come back or give up.
Store release, handled
Signed builds from an automated pipeline, plus the store listings and privacy details Apple and Google ask for. The code lives in your repository from day one.
How an engagement runs
A demo every two weeks. No six-month silences.
Most projects start with a short, fixed-price discovery and move in two-week sprints you can stop, pause or extend.
From discovery to launch
Weeks 1–2
We learn the game before we play it
What happens
We sit with your users, your constraints and your numbers. Then architecture, scope, and the honest version of what fits your timeline — including the parts we would cut.
What you get
A scoped plan with a real budget, a technical architecture you own, and a working prototype of whichever part carries the most risk.
Fixed priceYours to keepNo obligation to continue
Two-week sprints
A demo at the end of every sprint
What happens
Design and engineering run together rather than in sequence. Every sprint closes with something you can click — never a status report standing in for progress.
What you get
A product growing in front of you, written status every week, and a direct line to the engineers writing the code.
Demo every two weeksYour repository from day oneRe-scope between sprints
Launch and after
We stay on past the launch party
What happens
A security review, a performance pass, and a handover your team can actually act on. Then we watch the first weeks of real traffic alongside you.
What you get
Production infrastructure in your accounts, documentation and training, and a support arrangement sized to your stage.
Security reviewed before launchFull handover and trainingSupport that answers
Expertise
The tools, and who it suits.
Technologies we use
- Apps
- Design
- Backend and APIs
- Cloud and delivery
A good fit when
- People will use it often, on the move, and sometimes with poor signal.
- It needs the phone itself — notifications, the camera, location or offline storage.
- You want iOS and Android from one team, and ideally one codebase.
- You want to own the code, in your own repository, from day one.
Probably not the right fit when
- People will visit now and then and need no phone features. A fast mobile website will serve them better, so start with web development.
- You want your existing website wrapped up as an app. Store reviewers can turn those down, and it gives people nothing the website does not already do.
Questions
Mobile App Development: your questions.
Should we build with Flutter or go native?
For many business apps, Flutter is the sensible default: one codebase for iOS and Android, so features ship to both together and there is one set of code to test and maintain. Native Swift earns its place when an app leans heavily on iOS-specific features, needs new Apple features the day they appear, or will only ever run on iPhone. Plenty of apps are mostly Flutter with a few native parts — we decide in discovery and explain the choice in plain English.
Do we need an app, or would a website do?
If people visit now and then, a fast mobile website is usually less to build, easier to update and needs no download. An app earns its place when people use it often, need it with poor signal, or rely on notifications, the camera or location. We will tell you which during discovery, even when the answer is the smaller project.
How long until our app is in the App Store and Google Play?
Every project starts with a short, fixed-price discovery, usually one to two weeks. A focused first version is usually six to twelve weeks, built in two-week sprints with a working demo at the end of each — a build you can install and try on your own phone. Store review adds time that neither of us controls, so we submit early and plan the launch date around it.
Will the app work offline?
It can, and how much is a decision we make together in discovery. Most apps should at least stay usable when the signal drops: showing what was last loaded, keeping what the user entered, and syncing when the connection returns without losing or duplicating anything.
Do you build the backend and admin side too?
Yes. Most apps need an API, a database and screens where your team manages users, content or orders. We usually build those with Node.js, GraphQL and PostgreSQL, running in your own AWS or Azure account, so the whole system is yours.
What happens after the app is live?
Apple and Google release new versions of iOS and Android every year and update their store rules, so an app needs looking after. A support arrangement sized to your stage covers fixes, OS updates and new features, and the analytics show you what is worth building next.
Further reading
From Step2Play Insights.
Product development
How to Turn a Business Idea into an MVP
A practical path from idea to a first version real users can try: what to build, what to leave out, and how to know it worked.
Product development
How Much Does Custom Software Development Cost?
The factors that really drive the cost of custom software, why fixed quotes on vague scopes go wrong, and how a short discovery turns a guess into a budget.
Often paired with
Related services.
UI/UX Design
Research, flows, design systems and prototypes — so the first build is the right build.
Web Development
Fast, accessible, responsive web applications. React and Next.js, from first prototype to production.
QA & Testing
Automated testing, penetration-test remediation and managed support once you are live.
Get in touch
Tell us what you’re building.
Send a short brief and you’ll hear back from a real engineer within one working day — not a sales script.
We use what you send here to reply and to follow up on your enquiry. We never sell it or share it for marketing. Privacy policy.