Cube of spheres, the studio mark

12 years building custom software

Apps people keep on the home screen

Marketplaces, services and the money moving between two sides of them. Our own app carries 30 integration tests that drive it on a real device — you can open the demo and try to break it.

See our work
Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//Mobile Development//
Sound familiar

The app conversation usually starts one of these ways

  • “Our customers keep asking for an app, and we do not know if they would actually use one.”

    Asking for an app usually means something is awkward on the website. Worth finding out which thing before paying for a store presence.

  • “We were quoted for iOS and Android separately and the total doubled.”

    Sometimes two native apps are genuinely right. Far more often they are two codebases and two sets of bugs for one product.

  • “The last studio delivered something that worked on their phone.”

    A mobile app meets permissions, payment sheets, notifications, background kills and a network that drops. None of that shows up on a developer’s desk.

  • “It is in the store, but every release is a week of panic.”

    Store review turns a small fix into a multi-day event unless releases are automated and tested. The panic is a process problem, not a platform one.

The first release

What mobile app development costs here: one journey, both stores, eight weeks

from $19,000
Paid by stage, and no stage grows unless the scope changes — a change is quoted before the work starts. Dearer than the web: two platforms, two store reviews, runs on real devices.
Eight weeks
From the first call to a build your customers can install. You can stop after any stage.

What you get

  • One journey that matters, working end to end on iOS and Android
  • Cross-platform by default — we will say plainly when native is the honest answer
  • Accounts, sign-in and the states around them: expired sessions, lockouts, password reset
  • The backend it needs, or the integration with the one you already have
  • Push notifications, permissions and the payment sheet — the parts that live outside your app
  • Integration tests that drive the real app on a real device, running in your pipeline
  • Both store listings submitted, with the account and the signing keys in your name

What is not included

  • Everything the web version does. The first release is one journey, deliberately
  • A design system for a product that has not met users yet
  • Ongoing store optimisation, screenshots and ad campaigns
  • Games, AR, and anything that lives or dies on frame rate — not our trade
  • Guaranteed review times. Apple and Google decide those, and anyone promising otherwise is guessing
30
integration tests driving our own app on a device
173
backend tests asserting the same flows from the other end
24
suites they are split across, named after what they protect
What ends up working

The journeys we cover, and where each one has to survive

An app is not one product, it is the same product on two platforms and a server between them. This is the shape of a first release; switch off a platform you do not need and the list answers for your case.

Your product runs on
Which journeys are covered on which surface
JourneyiOSAndroidBackend
Sign-in, sessions and password resetIncluding the token that expires mid-session and the lockout after failed attempts.Covered · iOSCovered · AndroidCovered · Backend
The one journey the product exists forAn order placed, a job accepted, a piece of work delivered — the thing people install it for.Covered · iOSCovered · AndroidCovered · Backend
Payments and money held between two sidesThe payment sheet lives outside your app, which is exactly why it needs a test that leaves it.Covered · iOSCovered · AndroidCovered · Backend
Push notifications and permissionsThe system dialog is not part of your app and cannot be tested from inside it.Covered · iOSCovered · AndroidCovered · Backend
Chat and delivery receiptsTwo devices, one conversation, and a message that must not silently vanish.Covered · iOSCovered · AndroidCovered · Backend
Poor network and the app killed in the backgroundAndroid kills backgrounded apps eagerly. Coming back to a working screen is a feature.Covered · iOSCovered · AndroidNot covered · Backend
Store release and signingAccounts and keys in your name from the start, so you are never locked out of your own product.Covered · iOSCovered · AndroidNot covered · Backend
Admin side: moderation, disputes, refundsRuns in the browser. Nobody wants to settle a dispute on a phone.Not covered · iOSNot covered · AndroidCovered · Backend
20 checks — 8 journeys across ios, android, backend
under testnot on this surface

Empty cells are deliberate, and the list is negotiable: when the budget is tighter than it, we say which journey goes first and which waits. An app that claims every journey on every surface has never run on a real handset.

Cross-platform is usually right, and we will say when it is not

One codebase, two stores, one set of bugs — for marketplaces, services and anything whose value is in the flow rather than the frame rate, Flutter is simply the cheaper honest answer, and it is what our own marketplace runs on. Native earns its cost when the product leans on something platform-specific: heavy camera or sensor work, deep OS integration, sustained animation at sixty frames. We would rather lose the bigger quote than sell you two codebases you do not need, and we say which one you are in during the first call.

The marketplace this runs on

The interesting failures live outside your app

The permission dialog, the payment sheet, the push notification arriving while the phone is locked, the app killed in the background and reopened three days later — none of these are your code, and all of them break your product. They are also invisible to the tests most studios write, because those tests never leave the app. We use Patrol precisely because it can reach the parts of the phone that live outside it, and that is why our own suite can assert a deposit paid by card when the wallet is empty, rather than asserting that a button existed.

Tested on real devices, not on a developer’s optimism

Our own app carries 30 integration tests across 30 journey files, plus 173 backend tests in 24 suites that assert the same flows from the server side — so a payment is checked from both ends rather than at whichever end is convenient. The files are named after what they protect: deposit_cardpay, deposit_terminal, token_refresh, reset_lockout, two separate arbitration flows for when two people disagree about one order. You get the same shape: a suite in your repository that runs on every push.

The same discipline sold on its own

Releases are a routine, not an event

Signing keys and store accounts in your name from week one, builds produced by the pipeline rather than by whoever has the right laptop, and a release that is a tagged commit. Store review still takes what it takes — Apple and Google decide that, and we will not promise you a number — but everything up to the submit button stops being a week of panic. If you already have an app in the stores, we can take over that part alone.

The app is half the product; the other half is the server

Almost every app worth building is a client for something: accounts, money, moderation, disputes, the admin screen where a human sorts out what the app could not. We build that side too, in the same eight weeks when the journey is small enough, and it is where the genuinely hard decisions live — who holds the money, what happens when both sides claim they are right, what the system does when a payment half-succeeds.

Who holds the money, and why it shapes everything

And what we do not do

  • We do not promise store review times. Nobody can, and the ones who do are guessing with your launch date.
  • We do not build games or anything that lives on frame rate. Different craft, and you deserve someone who does it daily.
  • We do not publish under our own developer account. It is your product; the account and the keys are yours.
  • We do not ship a first release without tests on the money path. It is not an upsell, it is the part that wakes you at night.
How it runs

Eight weeks, and an installable build from week two

You do not wait for a reveal. From the second week there is a build on your phone that gets better every few days, which is also how you find out early whether you want to keep going.

  1. Week 1

    The one journey, and the platform decision

    Sessions with the people who will use it, a walk through what exists, and an honest answer on cross-platform versus native for your product specifically — not for products in general.

    You seeAgreed scope, the platform decision with its reasoning, and store accounts opened in your name.

  2. Weeks 2–3

    A build on your phone

    Sign-in, navigation and the spine of the journey, installed on your device through the test channels. Rough, real, and yours to poke at daily.

    You seeAn installable build, and the first list of things you want different.

  3. Weeks 4–6

    The hard half

    Money, notifications, permissions, the states nobody demos: no network, expired session, app killed in the background. Integration tests grow alongside on a real device.

    You seeThe journey works end to end on both platforms, including its failures.

  4. Week 7

    Real people, real handsets

    Your team uses it on their own phones — old Androids included, because that is what your customers have. Everything found is fixed or triaged in the open.

    You seeA build that survived a week of real use, and the tests that now cover what broke.

  5. Week 8

    Submitted, and handed over

    Both listings submitted from your accounts, the pipeline producing signed builds, a walkthrough with whoever will own the code, and a runbook written against your app.

    You seeApps in review, and a developer on your side who has shipped a build themselves.

  6. After

    Whatever the users tell you

    The first release exists to be argued with by real people. Phase two is quoted from what they actually did, not from what the plan assumed they would.

    You seeA decision made on usage, not on opinion.

What it is usually built with
  • Flutter
  • Dart
  • Patrol
  • NestJS
  • PostgreSQL
  • Firebase
  • GitHub Actions
What you keep

The part nobody shows you before signing

Both screenshots come from our own marketplace app — the suite that drives it on a real device, and one of the journeys inside it. Real files, not a mock-up.

A Patrol integration test file explaining the deposit card-fallback journey it covers

A journey written down so a person can read it

Every test opens with what it protects and why, in plain English, because a suite nobody can read is a suite nobody maintains. This one proves a deposit can be paid by card when the wallet is empty — a path that quietly breaks in a lot of marketplaces and takes months to notice.

From the integration suite of our own marketplace app.

Terminal listing of thirty Patrol integration test files named after the journeys they cover

And thirty of them, named after what they defend

Not "test_1" and "test_2". Deposits by card and by terminal, token refresh, lockout after failed sign-ins, two arbitration flows, chat receipts, work submission. When one goes red you know what broke before opening anything.

Listed straight out of the repository, 15 August 2026.

Be honest with yourself

An app is worth building for some products and a distraction for others

Buy this if

  • People would use it more than once a week — otherwise the browser is enough
  • The product needs something a phone has: a camera, a location, a notification that arrives
  • There are two sides to serve, and money or trust moves between them
  • You are prepared to keep it alive: stores expire builds and platforms change yearly
  • Someone on your side can answer domain questions and test on their own phone

Do not buy this if

  • A mobile-friendly website would do the same job — we will say so, and it costs you nothing to ask
  • You want it because competitors have one; that is not a reason a user will install it
  • The idea has not been tested with anyone yet — the store is an expensive place to learn
  • Nobody will maintain it after launch; an unmaintained app is worse than none
  • You need a guaranteed launch date. Store review is outside anyone’s control, including ours

If the honest answer is "you do not need an app yet", you will hear it on the first call. It has cost us work more than once and it has never cost us a client.

Questions we get about building an app

Short answers. The long ones happen on the call.

A first release with one journey working on both platforms starts at $19,000 for eight weeks, paid by stage — no stage grows unless the scope changes, and a change is quoted before the work starts. A full product runs further: our own marketplace took four months, including the backend, the money handling and the admin side. Want the scope pinned down first? The spec-and-prototype stage is priced on its own, and its fee comes off the project.

Cross-platform, usually. One codebase and one set of bugs, which for marketplaces and service apps is simply cheaper. Native earns its cost when the product leans on the platform itself: heavy camera or sensor work, deep OS integration, sustained animation. We tell you which one you are in during the first call, including when that answer costs us the bigger quote.

If you are cross-platform, both cost almost the same as one, so usually yes. If your users are overwhelmingly on one platform — check your website analytics before deciding, not your intuition — starting with that one and adding the other after real feedback is a perfectly good plan.

Usually a day or two, occasionally a week, and neither we nor anyone else controls it. What we can control is that the submission is clean the first time: correct permissions and their explanations, working test accounts for the reviewer, and no half-finished screens. Most rejections we see are avoidable paperwork, not code.

With Patrol, which drives the app the way a person does and can reach the parts of the phone outside it — the permission dialog, the payment sheet, a push arriving while the screen is locked. Our own app carries 30 such tests across 30 journeys, plus 173 backend tests in 24 suites asserting the same flows from the server. Most studios test inside the app only, which is where the interesting failures are not.

Rarely the feature everyone reviewed. It is the session that expired overnight, the payment that half-succeeded, the app killed in the background and reopened on a broken screen, and the old Android nobody tested on. Those are exactly the paths we put under test first, because they are the ones you find out about from a one-star review.

You do, from your own accounts, with the signing keys in your name from week one. We set it up and drive the first submission with you watching. Publishing under a studio account is common and it quietly holds your product hostage — we do not do it.

Budget for the store fees, a modest server bill, and at least one release a year to keep up with platform changes — iOS and Android both drop support for old builds on their own schedule. Defects found in the first six months after handover we fix at our cost; an app nobody touches for two years usually needs paying for twice.

Selected work

The app we built and still run

Not a client logo on a wall. This is our own marketplace, tested the way described above, with a demo you can open right now and use on sample data.

Two-sided marketplace app · Creator economy

Marketplaces where the money sits in the middle

A marketplace with two sides, a payment held between them, and an AI studio that bills by the generation. The hard part is never the catalogue — it is deciding, in code, the exact moment money and files change hands.

Flutter on both platforms, four months to a working product with money held between two sides — and 30 integration tests driving the real app through deposits, token refresh, lockouts and two arbitration flows.

4 months
from kickoff to a working product
173
end-to-end tests, 24 suites
21
data models behind it
Live demo insideRead the case
Creator feed in the marketplace app, with an order button
Made-to-order production platform · Medical manufacturing

Operations platforms where every order is one of one

Made-to-order production has no catalogue and no reorder button. Every item is built for one person from measurements a computer takes off a scan, and the system has to hold that thread from the first appointment through manufacturing, delivery, and the remake eighteen months later.

The other half of what a mobile product usually needs: the browser side where a human moderates, settles disputes and reads the reports the phone was never the right place for.

8 months
and still building — the largest system we run
13
flow families, from intake to remake
2,053
automated checks across its three repositories
Live demo insideRead the case
Order board in the operations platform, with production stages
Every solution we build

Worth reading before you commission an app

All articles →
Mobile development

Native or cross-platform, in plain terms

One codebase or two is the first real decision in a mobile project and the one most often made for the wrong reasons. Four questions that settle it.

2 min read
Mobile development

The parts of a marketplace that only break after launch

The demo always works. What fails in month two is the paid order whose seller was banned, the deposit that half-arrived, and the dispute about a file nobody kept. A list worth reading before you sign anything.

5 min read

Talk to us about mobile app development

Tell us what you are building

A person reads it and sends an estimate within 12 hours: a price range, what the first version contains, and what moves the price.