Everything an App Needs, Ordered by When It Needs It
Not a menu of packages. These are the pieces of work an app passes through between somebody sketching it on a napkin and somebody still using it two years later — and all of them are mobile.
An App Has a Life, Not a Launch Date
Every service on this page sits at one of these five points. Knowing which point you are standing at is most of the decision.
Native or cross-platform, one store or two, the whole idea or the one workflow that proves it.
Flows, a screen inventory, then a prototype you tap through in your own hand before anyone writes code.
Sprints that each end with an installable build, plus the accounts, data and push infrastructure behind it.
Device QA, signing, declarations, submission, staged rollout, then a listing that says what the app is for.
New OS versions, expiring certificates, changed store policies, dead libraries, and what the analytics say to fix.
Stage five is the one most quotes leave out. An app that nobody touches for a year does not stay still — it quietly stops working.
What It Runs On
The first real decision, and the one that sets the budget. We build all of these, so we have nothing to gain from steering you.
iOS App Development
Swift and SwiftUI, built for the way iPhone users expect an app to behave — and for the review rules that decide whether it ships at all.
Learn moreAndroid App Development
Kotlin and Jetpack Compose, tested against the device spread Android actually has rather than the two handsets in the office.
Learn moreCross-Platform Apps
One codebase to both stores. We explain where the seams are before you commit, including the parts that still need native code.
Learn moreReact Native
The right choice when your team already writes JavaScript, or when large parts of the product logic can be shared with something you own.
Learn moreFlutter
Strong when the two platforms must look identical and the interface is dense — dashboards for staff, kiosks, heavily branded consumer apps.
Learn moreWearables & TV Apps
Watch complications, glanceable screens measured in seconds, and living-room interfaces driven entirely by a remote control.
Learn moreTurning It Into Something Installable
The middle of the life cycle. This is where most of the budget goes, and where scope discipline earns or loses you a launch date.
App UI/UX Design
Flows, a fixed screen inventory and a prototype you can tap through on your own handset. Thumb reach and one-handed use are constraints here, not afterthoughts.
Learn moreMVP App Development
The smallest version that is genuinely worth putting in a store. We argue about what comes out, not about what goes in, because that is the argument that saves money.
Learn moreEnterprise Mobile Apps
Apps for staff rather than the public: single sign-on, device management, role-based access, and distribution that may never touch a public store.
Learn moreApp Redesign & Rebuild
Taking on an app somebody else wrote. It begins with a paid audit and a straight verdict on whether the code is worth continuing or cheaper to replace.
Learn moreMobile Backend & APIs
Accounts, sync, push infrastructure and an admin view. Designed for a phone on a patchy connection rather than a browser on office broadband.
Learn moreThe Half of the Project That Happens After the Code Works
Code that runs on a laptop is not an app in a store, and an app in a store is not an app anybody has found. These six close that gap.
Testing & QA
Real handsets, old ones included. Low storage, weak signal, an interrupting phone call, a rotated screen, the largest accessibility text size.
Learn moreStore Launch & Submission
Developer accounts in your name, signing keys, screenshots, privacy and data-safety declarations, staged rollout and review correspondence.
Learn moreApp Store Optimisation
Title, subtitle, keyword field, the first two screenshots and the review replies. Most installs are decided before anyone reads your description.
Learn moreAnalytics & Monetisation
Knowing where people stop, and charging for the app without breaking store billing rules. Subscriptions, one-off purchases, restore flows and receipts.
Learn moreSecurity & Privacy
Keys that are not sitting in the bundle, tokens in the keychain or keystore, and permission requests asked at the right moment and justified.
Learn moreSupport Plans
The stage-five work: OS releases, certificate renewals, policy changes, dependency upgrades, crash triage and a small budget for changes.
Learn moreA First Build, Roughly in Proportion
People expect the coding to be the whole invoice. On a mobile project it is a little over half of it, and the stages either side decide whether the app survives.
Build and backend — the largest single share
Screens, business rules, the API, sync, push, and the admin view you use to run the thing.
Design and prototype — the cheapest place to change your mind
Usually a couple of weeks. Moving a screen here costs a conversation; moving it in month three costs a sprint.
Device QA — invisible until it is missing
Old handsets, small screens, flaky networks, refused permissions, and the interruptions a phone gets that a desktop never does.
Submission and listing — small, and non-negotiable
Accounts, signing, declarations, screenshots and review feedback. Inside our build prices rather than added at the end.
Proportions, not prices. Your split moves with the app — a hardware-heavy build pushes QA up, a design-led consumer app pushes design up. Put your own numbers in with the cost estimator.
What We Do Not Offer, and Why That Is the Point
A studio that says yes to everything learns each thing once. This is the list we say no to, published so nobody wastes a call.
Not on the list
- Web applications, customer portals and dashboards as products in their own right
- Desktop software for Windows or macOS
- Marketing websites, landing pages and content sites
- Ecommerce storefronts built on a shop platform
- General business software and internal tooling that never reaches a phone
- Standalone AI products, models and data platforms
Where the line sits
- We build the backend your app talks to, because an app without one is half a product
- We build the admin view you need to operate the app — approve, refund, configure, look something up
- We integrate with systems you already run rather than replacing them
- We will not take a mobile brief and stretch it into a web product you did not ask for
Why it is worth the lost work
- Store review rules change quietly, and only a team submitting constantly notices
- The rejection reasons repeat, and you learn them by collecting them
- Battery, cold start, app size and background limits are mobile problems with mobile answers
- A shelf of real handsets is only worth owning if something is installed on it every week
- If you need a web or desktop product, a generalist firm will serve you better than we would
If your project needs both an app and a substantial web product, say so on the first call. We will tell you honestly whether we should build the mobile half alongside someone else, or stay out of it entirely.
Choosing Between These
Do I have to buy all of these together?
No. Most projects are a build, which already folds design, device QA, store submission and a first listing pass into one price. The separate pages exist because some people arrive needing exactly one thing: a design review, a security look before a funding round, a rescue of an app someone abandoned, or a support plan for an app we did not write. Any of those can be bought on its own, and we will say so if the piece you asked for is not the piece you need.
Which platform should we launch on first?
Look at who has to use it. Consumer apps in most markets skew Android by device count and iOS by spend, so the answer changes with what you are selling. Internal and field apps usually follow whatever handsets the company already issues, which settles the question immediately. If the audience is genuinely split and the app is mostly screens and data, one cross-platform codebase covering both stores is normally cheaper than launching one native app now and a second one later.
Can you take over an app another developer built?
Yes, and it is a large part of what we do. It starts with a paid audit rather than a promise: we build the project from source, run it on real devices, read the code, check what the store accounts and signing keys look like, and give you a written verdict on whether the codebase is worth continuing. Sometimes the answer is that a rebuild costs less than repairing what exists. You get that verdict in writing either way, and it is yours to take elsewhere.
Is design a separate cost?
It is inside every build price. Mobile design is not decoration you add at the end; it is the screen inventory, the navigation model and the prototype that make a fixed price possible in the first place. The design page exists as its own service for the case where you only want the design work, usually because you have an in-house team who will build it.
Do you build the backend as well, or only the app?
Both, and on most projects the backend is where a surprising share of the effort goes. If you already have an API we will consume it, and we will tell you early if it is shaped for a web page rather than a phone, because that difference shows up as a slow, chatty, battery-hungry app. If you have nothing, we build the accounts, the data, the push infrastructure and the admin view alongside the app.
Not Sure Which of These You Need?
Describe the app in a paragraph. We will tell you which stage you are actually at, what it is likely to cost, and what we would leave out of version one.