What drives the cost of a custom web or mobile app
The cost drivers, in plain terms
| Driver | What pushes cost up | What keeps it down |
|---|---|---|
| Platforms | Web plus native iPhone and Android apps, each built separately | One mobile-friendly web app, or one cross-platform codebase for both stores |
| Users and roles | Many user types (customers, staff, admins, partners), each with its own screens and permissions | One or two roles in the first release |
| Features in release one | "Everything" at launch | One primary job, with other wishes on a later-phase list |
| Integrations | Payment gateways, CRM, accounting, inventory, SMS, government or partner APIs, especially old systems with poor documentation | Fewer integrations, and well-documented services |
| Data and admin tools | Custom dashboards, reports, approval flows, data migration from old systems | Standard admin tools and clean starting data |
| Design | Fully custom design and animation | A proven design system, adapted to your brand |
| Security and privacy | Personal or financial data, logins, payments and audit trails, all designed for Data Privacy Act obligations | Minimal personal data collected, and payments handled by the gateway so card data never touches your servers |
| Content | Content written, translated or photographed during the build | Content ready before development starts |
| Testing and release | Many devices and app store releases, plus formal acceptance testing | A defined test device list and a written acceptance checklist |
| Timeline | A fixed launch date that forces a bigger team | A realistic phase-one date |
| After launch | Unclear ownership, so every change becomes a project | A named owner, documented handover, and a support plan agreed up front |
Five questions that shape your quote
- What is the one job this app must do well in its first 12 months?
- Who uses it, and who runs it after launch?
- Which systems must it talk to on day one, and which can wait?
- What personal or payment data will it handle?
- What is explicitly out of scope for phase one?
Bring rough answers. Our guide to what scoping a web or app build should look like walks through these in more detail.
Ways to spend less without cutting corners
- Start with a web app if your users don't need phone-only features. You can add a mobile app later on the same backend.
- Use tools you already pay for. Some internal tools can start in Google Workspace or Microsoft 365 apps before a custom build. See AI Workflow Automation.
- Own your accounts from day one. Domains, hosting and app store accounts registered to your company prevent costly handover problems later.
- Build security in from the first release. Adding it after launch usually means rework.
Usap tayo
Send us your rough idea, even as bullet points. On a free 30-minute scoping call we'll work out the first release, the integrations and what stays out of scope, then follow up with a written scope you can get quoted. Book a scoping call
Frequently asked questions
How much does a custom web or mobile app cost?
It depends on what the app has to do, not on a standard price list. The biggest factors are the platforms you need, how many user roles and features you start with, which systems it must connect to, how much security and privacy work your data needs, and who runs it after launch. A short scoping call turns your rough idea into a written scope we can quote against.
Is a mobile app more expensive than a web app?
Often, yes. A mobile app adds app store accounts, review and release work, testing across phones, and updates for new operating system versions, and you may need a web admin panel as well. If your users don't need offline access, the camera, push notifications or daily use, a mobile-friendly web app may do the job for less.
What makes an app project cost more than planned?
Mostly scope that wasn't written down: integrations that were assumed, content nobody prepared, an admin panel that grew, and "small tweaks" that turned into new features. A written scope with a clear out-of-scope list, plus a change note for anything new, prevents most surprises.
Can we start small and add features later?
Yes, and it's usually the smarter path. Pick the one job the app must do well in its first release, launch that, and plan the rest as later phases. You learn from real users before you pay for features they might not use.
What ongoing costs come after launch?
Hosting, domain and app store accounts, security updates, bug fixes, operating system updates, monitoring and backups. Someone also has to own content and answer users. Ask for these to be listed in the scope so the first year has no surprises.
Why won't you give a price before a scoping call?
Because any number given before we know the scope is a guess, and guesses turn into change orders. After a scoping call you get a written scope for phase one, with what is included and what isn't, and a quote that matches it.
