Pricing and quotation guide
Mobile app interface design cost
App interface design costs depend on how much the app does and how carefully its edges are handled. A simple app with a few screens and one platform is a contained job; an app with accounts, payments, notifications, offline use and several user roles has many more flows and states to design, and each one needs testing and handoff. Designing for both iOS and Android adds platform variations. Store screenshots, icons and support for developers during build are further items that some quotes include and others do not.
It explains what drives app design cost, from flows and states to platforms and store assets, and how to compare quotes. No prices are given, because they depend on scope and provider; LetGetGrow sets out the cost for your project in a custom quotation.
Illustrative diagram
What drives app design cost
- Flows
- Sign-up, core tasks, settings, payments.
- States
- Offline, errors, empty, permissions.
- Platforms
- One, or iOS and Android variations.
- Testing
- Prototype rounds on real phones.
- Components
- A reusable library for later features.
- Extras
- Icons, store screenshots, animation specs.
Costs paid to third parties (separate from our fees)
- Participant incentives
- Device testing
- Developer accounts and tools
Ask whether animations are specified for developers, since they can add both design and build time.
Scopes compared
| Scope | What it covers | Relative cost |
|---|---|---|
| Simple utility app | Few flows, one platform | Lower |
| Consumer app | Accounts, notifications, both platforms | Moderate |
| Complex app | Roles, payments, offline, many states | Higher |
Pricing models
Fixed project fee
Suits you when
- Defined first version
Watch out for
- Change process
Phased
Suits you when
- Discovery first
Watch out for
- Deliverables per phase
Ongoing design time
Suits you when
- Regular releases
Watch out for
- Prioritising requests
One platform or two
Designing for both iOS and Android does not double the work, because much of the structure and visual identity is shared. But navigation, system controls and some layouts differ, and each needs checking. Ask how platform variations are handled in the quote.
The cost of states
Every flow can fail in several ways: no connection, a payment declined, a permission refused, a session expired. Designing those states adds time, but leaving them out means developers improvise, which often costs more and produces inconsistent results.
Example: designing a first release
Illustrative example — not a client case study
Situation: A start-up plans an app with many features but limited funds.
- Features are ranked and the first release is limited to sign-up, the core task and settings.
- All states for those flows are designed and tested on both platforms.
- Components are built so later features reuse them.
What this shows: The first release was fully designed and later features cost less. This example is illustrative.
Testing on devices
Testing prototypes on a range of phones, including smaller and older ones, takes time but avoids layouts that break on common devices. Include at least one round before UI is finalised.
Store assets
Store screenshots and icons can be forgotten until launch. Check whether they are in the quote, and allow for current store size requirements.
Comparing quotes
Check flows, states, platforms, testing rounds, components, animation specs, store assets, developer support, revisions and file ownership.
Keeping costs down
Limit the first release to core tasks, use standard platform controls where they work, reuse components and give designers access to developers early.
Judging value
Good value shows in a smooth build with few design gaps, fewer support requests and better store reviews about ease of use.
Custom controls
Custom sliders, pickers and gestures can make an app distinctive, but each needs designing for every state and building on each platform. Standard controls are quicker and familiar to users; save custom work for where it helps most.
Accessibility
Designing for larger text sizes, screen readers and contrast from the start adds little cost. Retrofitting an app that clips text or hides labels from screen readers means redesigning and rebuilding screens. Ask whether accessibility checks against criteria such as WCAG 2.2 contrast and target size are part of the design fee.
Support during build
Apps are built over weeks or months, and developers will have questions throughout. Agree how much designer time is included for answering them, reviewing builds against designs and designing small missed states. Without it, gaps are filled by guesswork.
Later releases
Each new feature needs flows, states and UI. A good component library and clear handoff files lower the cost of each release, because new screens assemble existing parts. Ask how future work would be priced.
Which devices to design for
Agree a list of screen sizes the design must work on, including small phones and, if relevant, tablets. Each extra layout adds time, so base the list on the devices your users actually have, from analytics where available.
Questions about mobile app interface design cost
What affects app design cost most?
Flows, states, platforms and testing.
Does designing for two platforms double the cost?
No, but variations add time.
Why pay for state designs?
Developers otherwise improvise, often at higher cost.
Are store screenshots included?
Check; they are often separate.
How can we reduce app design cost?
Limit the first release and use standard controls.
How do we know app design spending paid off?
Smooth build, fewer support requests, better reviews.
Request a Custom Quote
Ask about Mobile app interface design cost
Thank you — your enquiry has been sent.
We have received your message and will reply by email. If you need to add anything, email info@letgetgrow.com.