The short version: the cheapest quote is rarely the cheapest app. Before you sign, make sure you know exactly what's being built in the first version, how changes are priced, that you will own the code in writing, that the app store, hosting and domain accounts are in your name, how your customers' data is protected, and what support costs after launch. A good developer will be glad you asked.
Prepare before you talk to anyone
Developers can only quote accurately for what they understand. One page of preparation will get you better quotes and save hours of meetings. Write down:
- The problem, in business terms: "we lose track of jobs between the office and the vans", not "we need an app with a dashboard".
- Who will use it: staff, customers, managers, and on what devices.
- The must-haves for a first version, and the nice-to-haves that can wait.
- What it must connect to: accounting, payments, booking, CRM, your website.
- Your budget range and any deadline, and why the deadline exists.
Not sure you need an app at all? Read Do I need a custom app? first. Sometimes better-connected off-the-shelf software does the job.
Experience and fit
1. Have you built something similar, and can I see it?
Not the same app, but the same kind of thing: a booking tool, a field-service app, a customer portal, a system that connects to accounting software. Ask to see it working, not just screenshots.
2. Can I speak to a past client?
A reference call is the best due diligence you can do. Ask that client how changes were handled, whether it came in on budget, and what happened after launch.
3. Who will actually do the work?
Will the people you meet be the people who build it, or is the work passed on to subcontractors? Either can work well, but you should know, and you should know who your day-to-day contact is.
4. How much do you need to understand about our business?
Good developers ask a lot of questions about how your business works before talking about technology. If the first meeting is all features and frameworks, be wary.
Scope and process
5. How do you work out exactly what to build?
Look for a discovery or design stage that ends with a written specification and screen designs you can see and approve before the build starts. It's the cheapest point to change your mind.
6. What's in the first version, and what isn't?
A focused first version that solves the main problem, released and used, beats a giant build that takes a year. Get the list of what's included in writing.
7. How do you handle changes?
Requirements always change once people see the app. Ask how change requests are estimated and approved, so nothing gets added to the bill without your agreement.
8. How often will I see progress?
Regular demonstrations of working software, every week or two, mean problems surface early. "You'll see it at the end" is a warning sign.
Technology choices
9. Web app, cross-platform or native, and why?
The right answer depends on your users, not the developer's preference.
| Approach | What it is | Best for |
|---|---|---|
| Web app | Runs in the browser on any device, with a login. No app store. | Internal tools, portals, dashboards. Usually the quickest and cheapest to build and maintain. |
| Cross-platform | One codebase produces both iPhone and Android apps. | Apps for customers or field teams that need store distribution, offline use or the camera, on a sensible budget. |
| Native | Separate apps built specifically for iPhone and for Android. | Apps that push the phone's hardware hard or need the very best performance. Usually the most expensive. |
10. What happens when Apple, Google or browsers release updates?
Phone operating systems update every year, and apps sometimes need changes to keep working or stay in the stores. Ask who handles this and how it's charged.
11. Where will it be hosted, and who pays for it?
Know the hosting provider, the likely monthly cost, where the data is physically stored, and whose account it sits in.
12. Will it connect to the software we already use?
Ask how they'll connect to your accounting, payments or booking tools, and what happens if one of those suppliers changes its system. Our guide to integrations explains the options.
Ownership: the questions people forget
This is where small businesses often get caught out, and where a few minutes of reading saves a lot of pain.
13. Will we own the code and designs, in writing?
Under UK copyright law, the author of a work is normally its first owner. Employees' work belongs to their employer, but if you hire an outside developer, they own the copyright in the code unless it's assigned to you, and an assignment of copyright must be in writing and signed by the owner. Paying the invoice doesn't by itself make you the owner. Make sure the contract assigns the intellectual property to you on payment, or at the very least gives you a clear, permanent licence to use and change it. Take legal advice if the app is important to your business.
14. Will we get the source code, and where will it live?
Ask for access to the code repository throughout the project, ideally in an account your business owns, plus any documentation needed for another developer to pick it up.
15. Whose name will the accounts be in?
The Apple and Google developer accounts, the hosting account, the domain name and any paid services should be in your business's name, with the developer added as a user. If they're in the developer's name and you part company, getting them back can be slow or impossible. Note that Apple asks organisations enrolling in its developer programme for a D-U-N-S number, which can take time to obtain, so start early.
16. What third-party components and licences does it use?
Most apps use open-source libraries and paid services. That's normal, but ask for a list, and check whether any carry ongoing fees or licence conditions.
Get an app quote you can actually compare. A written proposal that answers the questions in this guide: scope, ownership, accounts, hosting, support and price.
Cost and contract
17. Fixed price or time and materials?
A fixed price gives you certainty for a clearly defined scope; changes cost extra. Time and materials (paying for hours worked) is more flexible but less predictable. Many projects combine them: a fixed price for design and a defined first version, then agreed rates for later improvements. Either way, ask for an estimate broken down by feature.
18. How are payments scheduled?
Payments tied to milestones you can see (signed-off designs, a working first version, launch) protect both sides. Be cautious of paying most of the money up front.
19. What's not included?
Common extras: content and copywriting, data migration from spreadsheets, app store set-up, hosting, third-party subscriptions, training and post-launch support. Get them listed.
20. What will it cost to run each year?
Budget for hosting, support and updates. If it's a store app, there are also store fees: Apple's developer programme costs US$99 a year (charged in local currency where available) and Google Play charges a one-off US$25 registration fee. Both stores also take a commission on digital goods and subscriptions sold inside an app, while payments for physical goods and real-world services are generally handled outside the stores' payment systems.
Security and data protection
21. How will our customers' data be protected?
Ask about encryption, password handling, user roles and permissions, backups, and how they test for security weaknesses. If the developer will host or access personal data for you, UK GDPR expects a written contract covering how they process it. The government-backed Cyber Essentials scheme is a useful baseline for any supplier handling your data.
22. Where is the data stored, and can we get it out?
Know which country it's hosted in, and make sure you can export all your data in a usable format whenever you want, including if you change developer.
Testing, app stores and launch
23. How do you test, and how do we test?
Ask how they test before handing anything over, and how you'll test it with your own staff and real examples before it goes live. Ask about accessibility too: building to the WCAG accessibility guidelines makes the app usable by more people, including customers with disabilities.
24. Will you handle app store submission?
Both Apple and Google review apps before they're published, and they can reject them. Google also requires newer personal developer accounts to meet testing requirements before an app can go live, which is one more reason to use a business account. An experienced developer will know the rules and plan time for review.
Support after launch
25. What happens after launch, and what if you disappear?
Ask what support costs, how quickly they respond to problems (especially if the app stops working), how improvements are priced, and what happens if they stop trading. Your protection is ownership of the code, access to the repository, documentation and accounts in your name. For business-critical software, some companies also use a software escrow arrangement.
Red flags to watch for
- A firm price before they understand how your business works.
- No written specification, or a vague one-page "proposal".
- Reluctance to put code ownership in the contract.
- App store, hosting or domain accounts registered in their name.
- Most of the money up front, with nothing to see for months.
- No mention of testing, security, data protection or support costs.
- Pushing a native mobile app when a web app would clearly do.
- No past work they can show you running, and no client you can call.
Comparing quotes
Quotes for the same app can differ hugely because they're quoting for different things. Put them side by side and check each one covers:
Only once every quote covers the same ground is it fair to compare prices.
What a good proposal looks like
A proposal is the document you'll fall back on when there's a disagreement, so it's worth reading properly. A good one is written in your language, not the developer's, and you should be able to hand it to a colleague who wasn't in the meetings and have them understand what's being built. Look for:
- The problem in your words. If they've understood your business, it shows in the first paragraph.
- Who uses it and what each person can do. For example: "office staff create jobs; engineers see their own jobs and upload photos; managers see everything".
- A feature list for version one, with anything deliberately left out listed separately so there's no confusion later.
- What it connects to, and how, including what happens if a connected system is unavailable.
- Stages, with dates and payments attached to things you can see and approve.
- Assumptions: what they're expecting from you (content, data, decisions, access to other systems) and by when.
- Ownership, hosting and support terms, in plain sentences.
- Running costs for the first year after launch, not just the build price.
If you can't tell from the proposal what you'll have at the end, how much it will cost to run, or who owns it, ask for it to be rewritten before you sign. Vagueness at this stage nearly always turns into cost later.
How we answer these questions ourselves
Since we're an app developer ourselves, here's how we answer the big ones. We start with a free 30-minute chat, then a written proposal with fixed prices. Our list prices are £2,200 for system design (a written specification and screen designs) and £3,300 for system set-up and development, with larger web and mobile apps quoted per project. Not VAT registered - no VAT added. We'll often recommend a web app over a store app if it does the job, and we build in stages so you see working software early. Ask us any of the 25 questions above; we'd expect you to.
App developer questions
Who owns the code when I pay a developer to build an app?
Under UK law, an outside developer normally owns the copyright in code they write unless it is assigned to you in writing, signed by them. Make sure your contract assigns the code and designs to your business, and take legal advice if the app is important to you.
Should I choose a fixed price or time and materials?
A fixed price suits a clearly defined scope and gives budget certainty. Time and materials suits work that will evolve. Many projects use a fixed price for design and a first version, then agreed rates for later changes.
Do I need a native app or will a web app do?
For internal tools, customer portals and dashboards, a web app is often enough and avoids app store fees and approvals. Native or cross-platform store apps are worth it for offline use, heavy camera use, push notifications or a large consumer audience.
What does it cost to put an app in the App Store and Google Play?
Apple's developer programme is US$99 a year (charged in local currency where available) and Google Play has a one-off US$25 registration fee. Both stores take a commission on digital goods and subscriptions sold in the app. Development, hosting and support are separate.
What should be in an app development contract?
The scope of the first version, the design and approval process, how changes are priced, a milestone payment schedule, assignment of code and designs to you, accounts in your name, data protection terms, testing and acceptance, and support arrangements after launch.
Sources
- legislation.gov.uk: Copyright, Designs and Patents Act 1988, section 11 (first ownership) and section 90 (assignment must be in writing)
- Apple Developer: What's included in the Apple Developer Program
- Play Console Help: Get started with Play Console
- NCSC: Cyber Essentials overview
- ICO: Contracts between controllers and processors
- W3C: Web Content Accessibility Guidelines (WCAG)
This guide is general information, not legal advice. Fees and store rules reflect publicly available information in October 2026.