Process
You should never have to ask how it is going.
Six phases, each with a stated output and a stated duration. A build on your phone every fortnight. Here is exactly what happens, and what we need from you at each point.
- 01 · Discovery1–2 weeks
Decide what is actually v1
Most failed app projects were scoped as v3. We pull your idea apart, map the flows, cut everything that will not change a launch decision, and write it down as a fixed scope.
We run a competitive teardown of the apps you are up against — what they charge, where their reviews complain, which flows they have already proven. Then we map every screen v1 needs and argue about what can wait. The output is a scope document specific enough to quote against and a proposal with one number, not a range.
You receive
- Flow map
- Prioritised backlog
- Fixed proposal
We need from you
Two or three working sessions, plus anything you already have: research, user interviews, a competitor list, sketches on a napkin.
- 02 · Design2–4 weeks
Make it real before it is expensive
Screens and a tappable prototype. Changing a flow in design costs an afternoon; changing it after the backend is built costs a sprint. You sign off on something you have held in your hand.
A design system first — type, colour, spacing, components — then every screen in v1, in light and dark. You get a prototype you can tap through on your own phone before any production code exists. Platform conventions are respected: an iOS app should feel like an iOS app, not an Android one wearing a costume.
You receive
- Design system
- All v1 screens
- Prototype
We need from you
One consolidated round of feedback per milestone. Scattered comments across four channels are how design phases double in length.
- 03 · Build6–14 weeks
Two-week releases, never a black box
You get a build on your device every two weeks, a written release note, and access to the board and repository the whole time. No demo-day surprises.
Two-week sprints. Every sprint ends with a build on your device, a written note of what changed, and a live board you can read any time. Code goes through pull requests with automated type checks, linting and tests before it can merge. Nothing ships to main because someone was confident.
You receive
- TestFlight / internal track builds
- Sprint notes
- Live board
We need from you
Roughly two hours a week: try the build, answer questions that block work, approve scope changes.
- 04 · Hardening1–2 weeks
Break it on purpose
Real devices, bad networks, low storage, denied permissions, interrupted payments. Plus a full pass against both stores’ review guidelines before we ever hit submit.
We test on a real device matrix, not just simulators — older Android hardware included, because that is what a large share of your users actually hold. Then deliberate abuse: airplane mode mid-payment, permissions denied, storage full, session expired, app backgrounded during upload. Finally a full pass against the App Review Guidelines and Play Developer Policy.
You receive
- Device matrix report
- Review pre-audit
- Perf baseline
We need from you
A round of hands-on testing from your side, and sign-off on the known-issues list before submission.
- 05 · Launch1 week + review
Submit, defend, roll out
Listings, assets, privacy declarations and submission on both stores. If a reviewer pushes back we write the response — that is our job, not yours.
Store listings written for search as well as for humans, screenshots and preview video produced, privacy nutrition labels and the Play Data Safety form completed accurately — inaccuracy there is a rejection and, later, a removal risk. We submit, we monitor review status, and if a reviewer objects we write the response and resubmit.
You receive
- Live listings
- Staged rollout
- Monitoring dashboards
We need from you
Developer account access (registered to your company) and a decision on launch date and rollout percentage.
- 06 · CareOngoing
Keep it alive
iOS and Android ship breaking changes every year. We handle upgrades, watch crash rates against an agreed threshold, and plan the next release with you.
Monthly dependency and OS upgrades, crash-free session monitoring against the threshold we agreed, review-response drafting, and quarterly roadmap sessions. If a release drops below the crash threshold, fixing it outranks every feature on the board until it is back.
You receive
- Monthly reports
- Upgrade PRs
- Roadmap sessions
We need from you
A standing monthly session, and a view on what the next release should prove.
Working together
Four habits that keep a project honest.
Almost every unhappy agency relationship is a communication failure wearing an engineering costume. These are cheap, and they prevent most of it.
A weekly call, same time
Thirty minutes. What shipped, what is next, what is blocked. Cancelled only when there is genuinely nothing to say.
A shared channel, not a ticket queue
Slack, Teams or WhatsApp — your choice. You talk to the people building the app, not an account manager relaying messages.
A board you can read
Linear or Jira, open to you, updated as work happens rather than the night before a status meeting.
Written release notes
Every sprint build comes with what changed, what to test, and what is knowingly incomplete. No guessing what the new build does.
Engineering standards
The floor, on every project.
Your repository, from commit one
Code lives in your GitHub or GitLab organisation from the first day, not ours. You can clone it, read it and take it elsewhere at any point.
A build on your phone every sprint
TestFlight for iOS, internal testing track for Android, every two weeks. Progress you can tap, not a status percentage in a spreadsheet.
Automated checks before merge
Type checks, linting, unit and widget tests, and a signed build run on every pull request. Nothing reaches main on trust alone.
A crash-free target in writing
We agree a crash-free session threshold before launch and monitor against it. If a release drops below it, fixing that outranks new features.
Accessibility is not a phase two
VoiceOver and TalkBack labels, contrast ratios, dynamic type and 44pt touch targets are acceptance criteria on every screen we build.
Handover that actually hands over
Architecture notes, environment setup, credentials inventory, runbook and a walkthrough call. Another team could pick this up without calling us.
FAQ
Everything else people ask.
If yours is not here, it is a good first email.
What does a mobile app actually cost?
A focused v1 on both platforms typically lands between a small, single-purpose utility and a full marketplace with payments and realtime features — the range is wide because the scope is. That is exactly why we start with a paid product sprint: you get a fixed number against a written scope instead of an estimate that moves. If the sprint tells you the idea is not worth building, that is a good outcome and a cheap one.
Native, Flutter or React Native — which do you recommend?
It depends on what the app does. Heavy camera, audio, Bluetooth, background processing or platform-specific UI: native Swift and Kotlin. Content, commerce, booking, social and dashboard apps where the two platforms should behave identically: Flutter or React Native, one codebase, roughly 60–70% of the cost of two native builds. We make the recommendation in discovery, in writing, with the trade-offs stated.
How long until my app is live?
For a well-scoped v1: 3–5 months from kickoff to a live listing, including store review. Discovery is 1–2 weeks, design 2–4, build 6–14, hardening 1–2, then submission. Apple review is typically 24–48 hours once you submit something that passes the guidelines — the delay people remember is usually a rejection loop, which is what our pre-submission audit exists to prevent.
Who owns the code and the developer accounts?
You do, entirely. The repository sits in your organisation from the first commit. The App Store Connect and Google Play accounts are registered to your company, with us added as users you can remove. Every credential, key and certificate is inventoried and handed to you. There is no lock-in mechanism in our contracts because we do not want clients who stay for that reason.
What happens if Apple rejects the app?
We handle it — writing the response, making the change, resubmitting. It is included, not billed as extra. We also audit against both guideline sets before submitting, which is why it rarely gets that far. The rejections that do happen are usually about account deletion, subscription disclosure, permission usage strings or login requirements, and all of those are decided during design, not at submission.
Will you work with our existing app or codebase?
Yes. We start with a paid technical audit: architecture, dependency health, test coverage, crash rates, build pipeline and the honest cost of continuing versus rewriting. Sometimes the answer is that a rewrite is not justified, and we will say so even though it is the smaller project.
Do you sign NDAs?
Yes, before any detail of your idea is discussed. Send yours or use ours.
What do you need from us to start?
One decision-maker who can approve scope, roughly two hours a week for reviews and questions, and any existing research, branding or user feedback. You do not need a specification document — producing one is part of discovery.
Start here
Ready to put a date on it?
Send us the idea. We will come back with the phases, the questions we would need answered, and a realistic launch window.
NDA on request · Reply within one business day