Skip to content
Cost guide

What actually drives the cost of building an app.

Most articles about app development cost open with a number chosen to win a search result and bury the caveats below it. This guide does the opposite: real bands from our 2026 rate card (a lean first release runs $30,000–55,000, a standard product $55,000–110,000), set against the five drivers that genuinely move them, and the engagement model that turns a band into a fixed, transparent quote before any build begins.

How to read the numbers on this page

Indicative 2026 bands, not a quote. What moves the number is complexity — integrations, compliance, data migration and the reliability bar you need on day one. Every engagement is priced fixed and in writing after a paid discovery sprint, and the sprint is credited in full against the build.

The cost drivers

Five drivers move every app budget.

  1. Scope — and the cut-line

    Scope is the largest driver by far: screens, roles, platforms, states. But the wishlist matters less than the cut-line — deciding what a chargeable first version must do, and what can wait, moves the budget more than any technology choice.

    What moves it
    • How many screens and roles v1 truly needs
    • Whether it ships on one platform or several
    • Offline, multi-language and permission complexity
    • What can wait for v2 without hurting launch
    Where the number lands

    A lean first release (2–3 engineers, 8–14 weeks) lands $30,000–55,000. A standard product with several roles, real integrations and an admin surface lands $55,000–110,000 over 12–20 weeks. The discovery sprint fixes the cut-line and the quote prices that line, in writing.

  2. Team seniority

    The hourly rate is the most misleading number in software. Senior engineers cost more per hour and less per outcome: fewer rework loops, architecture that survives growth, review on every change.

    What moves it
    • Who reviews every change before it ships
    • How much of the first version needs rebuilding
    • Whether early architecture decisions survive real usage
    Where the number lands

    A senior-weighted squad (4 engineers plus a delivery lead) runs $19,000–24,000 a month on a dedicated engagement. The mix is named in the discovery sprint and priced into one fixed quote, so you are never paying for someone's learning curve by the day.

  3. Integrations

    An app is rarely alone: payments, ERPs, telephony, legacy systems. Each integration adds discovery, edge cases and testing — and the quality of the other system's API often moves cost more than your feature list does. On TapTime, the clock-in UI was the small part; the real-time ERP sync is where the engineering lived.

    What moves it
    • How many external systems the app must talk to, and how well their APIs are documented
    • Whether data must sync in real time or on a schedule
    Where the number lands

    We publish no per-integration price: connecting to a documented REST API is a much smaller job than connecting to a twenty-year-old ERP. Integrations are the driver most likely to move a build from the lean band to the standard one. Each is scoped and priced individually in the discovery sprint, against your actual stack.

  4. Compliance and data protection

    Data-protection law, audit trails, data residency and industry rules are architecture decisions. Designed in from the first sprint they are a manageable line; retrofitted after an audit finds the gap, they are a rebuild.

    What moves it
    • Which regulations your data and market actually trigger
    • Audit-trail and data-residency requirements
    • How much is designed in early versus retrofitted later
    Where the number lands

    Compliance carries no standard price — the scope is set by your data and your market. What it reliably does is move the band upward, and regulated builds are the most common reason an engagement sits in the complex-platform band rather than the standard one. Which rules apply, and what they add, is named in the discovery sprint, while the quote can still reflect them.

  5. Maintenance and ongoing care

    An app is not done at launch. OS releases, dependency patches, monitoring and the features your users ask for next are a real, recurring cost — the one most estimates quietly omit. We have shipped FeelEat's stack for 9+ years with the same team, and that continuity is planned into the budget before launch.

    What moves it
    • OS and dependency updates that cannot be skipped
    • Monitoring, backups and incident response
    • The feature roadmap that appears once real users arrive
    Where the number lands

    Care runs from $550 a month across three fixed plans; the FAQ below itemises them. Care is quoted as its own transparent line alongside the build, and you accept the plan before launch, so the first monthly invoice is never news. Indicative band, not a quote — the fixed number comes out of a paid discovery sprint and is credited against the build.

Reading this for a live project?

Talk it through — no pitch
How the number gets fixed

From unknown to a fixed quote, in three steps.

  1. Paid discovery sprint

    $2,900–4,900 over 1–2 weeks, credited in full against the build that follows. We scope the product together: workflows, integrations, the v1 cut-line, the risks worth naming out loud. You pay for the sprint because the output has standalone value — a scope you could take anywhere. The first workshop and a high-level estimate are free — usually back within three working days.

  2. Fixed, transparent quote

    The sprint ends in a number, in writing: fixed milestones and a fixed budget against the scope we agreed. If scope changes later, the quote changes with it in the open, and you approve the difference first.

  3. Ongoing care

    After launch the same team stays on: monitoring, updates and the next iterations, planned as care rather than emergency invoices. That continuity is how FeelEat's stack has stayed shippable for 9+ years.

No open-ended day rates, no surprise invoices. 100% of the code, IP and infrastructure transfers to you, and we sign an NDA on request. Indicative band, not a quote — the fixed number comes out of a paid discovery sprint and is credited against the build.

Worked examples

What these drivers look like on real builds.

FeelEat — nine products, 9+ years, one team

The whole-lifecycle cost picture on one client: we have built and run FeelEat's Swiss operating stack (ERP portal, workforce apps, kiosks, connected fridges) for 9+ years, nine products on one architecture. That far in, maintenance is the engagement itself.

9+ yrs
Building FeelEat
200+
Corporate clients
−12 hrs
Hours saved / staff / week

FeelEat TapTime — where integration set the budget

A tightly scoped mobile build whose cost story is the integration: NFC, QR and biometric clock-in for multi-site hourly teams, synced in real time to the ERP that runs payroll. The clock-in screens took weeks; the ERP spine behind them took months, and that is where the payoff came from.

99.5%
Attendance accuracy
~80%
Faster payroll
~95%
Less buddy-punching
FAQ

Questions founders ask about app development cost

Anything we missed?

Put it in a brief. A senior engineer reads it and replies within one business day.

How much does it cost to build an app?

A lean first release with 2–3 engineers over 8–14 weeks lands $30,000–55,000. A standard product with several roles, real integrations, an admin surface and operational reporting lands $55,000–110,000 over 12–20 weeks. A complex platform, meaning multi-tenant, regulated, or migrating beside a live system, runs $120,000–250,000+. Which band you sit in is decided by five drivers: team seniority, scope, integrations, compliance and maintenance. Indicative band, not a quote — the fixed number comes out of a paid discovery sprint and is credited against the build.

Why publish bands instead of a single price?

Because a single price quoted before scope is known is just a priced guess. A band is honest: it tells you which conversation you are in, a two-month release or a year-long platform, without pretending we can cost your app from a web page. The exact number is fixed after the discovery sprint and holds unless you change the scope.

What is the single biggest cost driver?

Scope — specifically the cut-line. The budget moves most when you choose what the first paying version has to do and what can wait a quarter. Drawing that line is most of what the discovery sprint is for.

How do you stop the price ballooning mid-project?

The quote is fixed against a written scope with fixed milestones, so there is no day-rate meter running. When scope genuinely changes, we reprice that change openly and you approve the difference before work continues. Nothing new gets billed before you have signed off on it.

Is a lower hourly rate a cheaper app?

Often the opposite. Junior-heavy teams cost less per hour and more per outcome: more rework loops, and architecture that needs rebuilding at the first sign of growth. That rebuild is the bill nobody shows you up front — which is why we price outcomes, not hours.

What does maintenance cost after launch?

One fixed line, visible up front. The recurring work (OS updates, dependency patches, monitoring, the roadmap your users create) is a care plan: $550 a month for 15 hours, $1,050 for 30, or $1,950 for 60 with a named engineer when the product is business-critical. The first 30 days after launch are warranty, and annual support typically runs at 15–20% of the original build cost. You accept the plan before launch instead of discovering it later — FeelEat has run on it, with the same team, for 9+ years.

What do I actually get from the paid discovery sprint?

A written scope: workflows mapped, integrations named, the v1 cut-line drawn, risks stated — and a fixed, transparent quote against it. That document is useful even if we never build together, which is why the sprint is paid work. If we do build, every line of code and all the IP end up in your name.

Ready to build

Have a problem worth
solving well?

Tell us what you are building and the deadline it has to meet. You will get a clear read on whether we fit and what the work would take.