Guides

App Development Quote Checklist

Updated 13 August 2026

An app-development quote can look reassuringly precise while leaving the expensive questions unanswered. A feature list, timeline and total price tell you what someone plans to build. They do not tell you whether that is the right first thing to build, what you will learn from it, or how easily you can change course.

Use this checklist before accepting a proposal or paying a deposit. You do not need perfect answers to every question. You do need answers specific enough that two sensible people would interpret them the same way.

The 12 questions

1. What business assumption does the first phase test?

“Build the app” is not an answer. The first phase should test something concrete: whether customers will sign up, complete the main task, pay, return, or trust the process. If the proposal cannot name the assumption, it is probably optimised for output rather than evidence.

2. What is the smallest complete user journey being delivered?

Ask for one journey written from beginning to end: who the user is, what they do, and what success looks like. “Authentication, dashboard and notifications” is a component list. “A clinic manager creates a shift, sends it to staff and sees who accepted” is a journey you can test.

3. What is explicitly excluded?

Good scope has edges. Ask for a written exclusion list covering roles, platforms, integrations, reporting, data migration, admin tools, content, testing and launch support. Unstated exclusions become change requests later.

4. What will be real, and what will be simulated?

A prototype does not need production-grade infrastructure behind every screen. Payments, notifications, matching, AI responses or back-office work can sometimes be simulated long enough to test behaviour. Ask where the proposal is deliberately faking complexity and why.

5. Which parts can be tested with real users before the full build is finished?

There should be a moment when evidence can change the plan. Ask what can be put in front of customers after week one, two or three, and which decisions remain reversible at that point. If users only see the product on launch day, the riskiest assumptions stay alive for the entire build.

6. Who owns the code, designs, accounts, domain and data?

The contract should name each asset and say when ownership transfers. Hosting, analytics, app-store, database, email and AI-service accounts should normally sit under credentials you control. “You own the app” is too vague if the agency controls everything needed to run it.

7. Can another developer take over without the original supplier?

Ask what the handover contains: source repository, environment configuration, deployment instructions, database schema, design files, account access and a short technical walkthrough. A maintainable handover is part of the product, not an optional favour at the end.

8. What ongoing costs sit outside the quoted price?

List hosting, databases, email, SMS, maps, payments, app-store fees, analytics, AI usage, support retainers and third-party licences. Ask for expected costs at launch and at a realistic early usage level. Small subscriptions can become structural dependencies.

9. What counts as accepted work?

Each milestone should have observable acceptance criteria. “Dashboard complete” invites argument. “An administrator can create, edit and archive a customer record on desktop and mobile” is testable. Also ask how long you have to review a milestone and how defects are handled.

10. How are changes priced and approved?

You will learn things during the build. The proposal should distinguish a defect from a change, explain who estimates new work, and require your written approval before cost or timeline changes. Beware of both extremes: unlimited changes promised casually, or every clarification treated as a paid extra.

11. What happens if the timeline slips or the relationship ends early?

Ask what you receive at each paid milestone, what happens to unfinished work, how notice works, and whether you retain access to everything already paid for. This is not planning for a fight. It is making sure both sides can make a clean decision if priorities change.

12. What would a smaller first engagement look like?

Ask the supplier to price the narrowest phase that produces evidence: a clickable prototype, a concierge test, one working user journey, or a technical spike for the genuinely risky part. A strong partner should be able to explain what can wait and what you need to learn before commissioning the rest.

Quick scorecard

One red signal does not automatically make a supplier bad. It means the risk is sitting with you and needs to be resolved in writing before money moves.

The decision to make before comparing prices

The most important question is not “Which quote is cheapest?” It is “What is the cheapest credible way to learn whether this business should be built?” Once that is clear, the scope becomes smaller, competing proposals become easier to compare, and good development partners can price the work with far less uncertainty.

This checklist is commercial guidance, not legal advice. Have a solicitor review material contracts, ownership terms and liabilities before signing.