Cost Estimator

What Will Your App Cost to Build?

Pick your stores, a rough screen count, and the things the app genuinely has to do. You get an indicative range and a delivery window straight away — no call, and no email needed to see it.

1. Which stores are you shipping to?

One choice, not two. Both stores from one codebase costs far less than two separate apps, and this prices it that way.

2. Roughly how many screens?

A screen is a distinct view someone can navigate to. A rough count is fine — do not go and draw a map.

3. What does the app have to do?

4. Anything that raises the bar?

This runs entirely in your browser. Nothing is sent anywhere unless you ask us for the breakdown by email using the form on the right.

Indicative Build Cost

Typically from kickoff to store approval

    An estimate, not a quote. A real number follows a scoping call.

    Want This Scoped Properly?

    We will look at what you picked and reply with a scoped estimate, a platform recommendation and a timeline.

    Reading the Number

    What Moves It, and What It Cannot See

    The estimator knows what you told it. These are the things it cannot know, and they are usually what separates the bottom of your range from the top.

    Pushes it up

    • Rules behind the screens — pricing tiers, approvals, permissions, anything with an exception list
    • Editing while offline, which means a sync queue and a decision about who wins a conflict
    • Anything running in the background: tracking, uploads, geofences, long-lived Bluetooth sessions
    • Selling digital content, which brings store billing, restores and receipt checks
    • A wide device matrix: old handsets, small screens, tablets, or hardware you do not control
    • Integrations with a system nobody can give you a test environment for

    Brings it down

    • One store first, with the second added once you know people use the app
    • Read-only offline: cache and display, rather than allowing edits that later have to be merged
    • A version one built around the single thing a user opens the app to do
    • Proven services for sign-in, payments, push and maps instead of building your own
    • Platform-standard components rather than a bespoke design language
    • Brand assets, copy and business rules ready at kickoff

    Not in the number

    • Apple and Google developer accounts
    • Paid APIs: maps, messaging, identity checks, payment processing
    • Cloud hosting and running costs after launch
    • Stock imagery, paid fonts, video and photography
    • Advertising and user acquisition
    • A support plan after the post-launch defect window closes

    The published pricing bands describe the same three shapes in more detail, including support plans and the fixed-price app audit.

    FAQ

    About This Estimate

    How close is this to a real quote?

    It is an order-of-magnitude tool. It should tell you reliably whether you are looking at a fifteen thousand dollar app or a seventy thousand dollar one, which is the question most people actually need answered before they start ringing studios. It cannot know how complicated the rules behind your screens are, and that is usually the difference between the bottom and the top of the range. The number narrows into a quote after a scoping call.

    Why is the platform a single choice rather than tick boxes?

    Because shipping to both stores is one decision with one price, not two independent purchases. Ticking iOS and then ticking Android would add two full builds together and hand you a figure roughly a third higher than the real one, since the design, the backend, the business rules and the store work are done once either way. Choosing both here prices a shared codebase covering both stores, which is what most apps should be.

    Why are design, testing and store submission already in the base?

    Because on a mobile project they are not optional, and pricing them separately is how surprise invoices happen. Every app needs a screen design and a prototype, every app has to be tested on real handsets rather than a simulator, and every app has to get through a store review with signing keys, screenshots and privacy declarations in place. A quote that leaves those out is not cheaper, it is just less honest about what it covers.

    What is deliberately not in this number?

    Third-party costs that are genuinely yours: the Apple and Google developer accounts, paid APIs such as maps or identity checks, cloud hosting once the app is live, stock imagery and paid fonts, and any advertising you choose to run. Ongoing support after launch is also outside it and is priced as a monthly plan. We set the third-party services up in your own accounts so you pay the list price directly rather than a marked-up version through us.

    Ready for a Real Number?

    Tell us what the app has to do and we will come back within two business days with a scope, a platform recommendation and a cost range.