Having an app built starts with a defined task for a recognisable user. The type of app follows from what that person needs to do on the move, at a desk or without a connection. You can then compare quotes against the same functions, platforms and support arrangements. Our custom software guide covers the wider process; the cost guide helps you put a budget together.
What does it cost to have an app built?
There isn’t a reliable standard price for an app without a defined brief. An appointment list for staff is a different job from a consumer app with subscriptions, media processing and customer support. Even the same number of screens can represent very different work: displaying a list needs different logic from a form that must preserve changes without a connection.
Build the budget around user actions. What happens when someone signs in, enters information, checks it, pays and recovers from a mistake? Ask which parts are priced and which still need investigation. A fixed price only helps you compare proposals when it comes with assumptions, exclusions and acceptance criteria.
Distinguish a clickable design from a working product, too. A prototype can show whether people understand the route. It doesn’t demonstrate that a payment is processed or an integration returns the right information.
Which type of app fits the brief?
Compare the options against the functions you need. A general claim that web is always cheaper or native always performs better doesn’t settle a specific decision.
| Approach | What you build | What to check first |
|---|---|---|
| Web app, possibly a PWA | An application accessed through a browser | Browser support, installation and offline tasks |
| Cross-platform app | Shared application code with releases for multiple platforms | Available modules and any custom platform code |
| Native app | An application targeting a particular platform | Required device features, maintenance and distribution |
| Existing package or app builder | Configuration on an existing platform | Functions, permissions, export, usage limits and subscriptions |
Cross-platform doesn’t mean every part automatically works the same way on every device. Flutter, for example, supports platform-specific code alongside the shared application. Ask how the developer handles missing functions and which devices they’ll test that solution on.
Offline use isn’t exclusive to native apps either. A web app can be designed for it. Our guide to progressive web apps explains the difference between a home-screen icon and actually continuing work without a connection.
What should you define before requesting quotes?
Describe a working day or user journey. Who opens the app, what are they trying to do and which data is available at that point? Include exceptions from the outset. A user may forget a password, interrupt an upload or submit the same request again.
A useful brief includes:
- The main task for the first release and what will wait until later.
- Roles: who can view, change or approve information?
- The systems supplying and receiving data, with available access.
- Devices and conditions in which the app must work.
- A description of what counts as a successful delivery.
Have the hardest assumption demonstrated early. For an inspection app, that might be a photo upload over a poor connection. For a subscription service, it could be access after a failed payment. These are possible test scenarios, not claims about a particular client.
What belongs in the quote?
A quote needs enough detail for you to assess the result. A screen list alone won’t do that. Use a breakdown such as this and ask the supplier to describe the outcome and assumptions for each part.
| Part | What you want to see |
|---|---|
| Research and design | Tested user journey and outstanding technical questions |
| App and backend | Functions, roles, storage and business rules |
| Integrations | Data direction, access, failures and recovery |
| Testing | Devices, scenarios and agreed acceptance criteria |
| Release | Accounts, store listing or web distribution, and handover |
| Ongoing operation | Responsibilities, recurring costs and change agreements |
For each integration, ask which system decides what data is correct. If the CRM and app can both change a phone number, the process needs a rule for handling that. The agreement is part of how the app works, even if the user never sees a separate screen for it.
Agree how changes after sign-off will be priced. A fixed price doesn’t eliminate additional work. The distinction between a defect and a new request needs to remain clear during the project.
How do you plan development and launch?
Ask for milestones with demonstrable results. A working user journey tells you more than a completion percentage. Integrations, exceptions and management functions can then be added and tested. Reserve time for your own review: without substantive feedback, a team can keep building without knowing whether it’s solving the right problem.
Separate technical delivery from public launch. Account verification, store review, content and user instructions may still require work after the app is technically ready. The schedule should identify dependencies the developer controls and those that sit with you or a platform.
The first release doesn’t need every future feature. It does need to handle the chosen task from beginning to end. Our MVP approach goes further into defining that scope.
What does app-store publication cost?
Prices checked in 2026-09: Apple lists the Apple Developer Program at 99 USD per membership year. Local pricing can vary by region. A Google Play Console account has a one-time registration fee of 25 USD. These are account charges, not the total cost of publication or operation.
Eligibility, account verification and applicable store rules also matter. Google lists additional testing requirements for certain personal accounts. Apple describes its assessment in the App Review Guidelines. Paying for an account doesn’t give you a guaranteed approval date.
Payment processing, subscriptions and any store charges need a separate assessment for your product and market. Don’t combine them into an arbitrary fixed allowance. A web app distributed through a URL doesn’t require an app-store account for that distribution route.
What should you arrange for operation and maintenance?
Distinguish the app on the device from the systems behind it. Hosting, storage, email, mapping services or AI usage may have their own charges. Maintenance can include fixing defects and adapting to operating-system or integration changes. New product functions belong in a separate budget.
Ask how failures are detected and who has the access needed to resolve them. Document how backups are restored and how a failed release is handled. Match those arrangements to the consequences for your users: an internal weekly report presents different needs from an app customers use to order during opening hours.
Quantum Life is an actual app project. Together with Aery, we built a Flutter app and web portal sharing account and payment logic. The case shows why a mobile app often extends beyond the screens on a phone. That project’s scope isn’t a price indication for your idea.
How do you assess ownership and handover?
At TopDevs, the code is and remains yours. Also document third-party components and their licences or subscriptions. Owning code alone doesn’t make a handover work: accounts, configuration, documentation and access to data are needed too.
Ask the supplier how another team could release a version and operate the service. Our guide to code ownership and vendor lock-in explains that distinction.
How do you actually get started?
Write down the main user journey and gather examples of the data involved. List the devices, required integrations and the situation that concerns you most. You can then assess a proposal by how the product works and what it costs, rather than by the number of screens drawn.
Read about our approach to app development or book a call. We’ll help define the first release and identify which assumptions need a practical trial first.
