"How much will my app cost?" is usually the first question. The next one should be: "What does that price include?"
A booking app might simply collect a request for staff to confirm. It might also check live availability, take payment, handle refunds and coordinate several branches. Those are very different projects, even if both quotes use the same name.
Describe the first release
Before asking for an estimate, write down who uses the app, what they need to do and which platforms they need. Include the staff workflow and the systems the app must connect to.
For a small appointment app, the first release might let a customer choose a service, request a time and receive confirmation from staff. Live calendars and payments could wait if manual handling meets the business need.
The app planning guide helps turn those decisions into a brief a developer can estimate.
Ask for a breakdown
Here's a made-up example for that limited appointment-request app. These hours show how an estimate can be structured; they aren't market rates, an Eleventor quote or a delivery promise.
| Work | Example hours | What you should receive |
|---|---|---|
| Requirements | 12 | Agreed flows, scope and acceptance criteria |
| Interface design | 18 | Screens, including loading and error states |
| App and backend development | 60 | Customer requests and staff handling |
| Testing and corrections | 24 | Checks on the agreed devices and scenarios |
| Release and handover | 10 | Release preparation, access and setup notes |
| Total | 124 | The agreed first-release work |
With one hourly rate R, the example's labour cost is 124 x R. If different roles have different rates, multiply each role's hours by its rate and add the results.
Ask for the currency, tax treatment, exclusions and proposal expiry date. Keep third-party charges separate so you can see what you're paying the developer to build.
Find the work hidden behind a feature name
Payments need failure and refund handling. Offline changes need storage, retries and decisions about conflicting edits. Another user role brings permissions and extra tests.
An integration can also depend on a provider's API or the access available on your account. Ask the team to investigate uncertain requirements before treating them as straightforward development work.
For platform choices, our native versus cross-platform guide explains what to compare.
Budget for the app after launch
Hosting, storage, messaging, monitoring and platform accounts can create recurring costs. The app may also need bug fixes, compatibility updates and support.
Clarify what's covered after handover and how new features will be estimated. Release preparation can be included in a proposal, but store approval is a separate process.
When comparing quotes, put the deliverables and exclusions beside the price. A lower total is useful only when it covers the work you need.
