Having an app developed: what to check? The 12-point checklist

01Before the enquiry: three things to settle yourself

• The goal in one sentence: which problem does the app solve, for whom? If you can't say it in one sentence, you'll receive quotes that can't be compared.
• A budget range: a realistic range saves both sides weeks — for orientation: simple apps €15,000–50,000, mid-complexity €50,000–100,000, details on the costs page.
• Must-have features vs. wish list: three to five must-haves for the first version. Everything else is a later stage.

02Contract and ownership (points 1–4)

• 1. Code ownership: the complete source code passes to you with all rights, documented and handed over. Without this point you are locked in for every follow-up order. At appDev this is standard in every project.
• 2. Understand the pricing model: fixed price for a fixed scope, or time and materials with a cap and stage approvals. Both extremes are warning signs: a “fixed price” without a requirements phase as much as an open-ended time budget without a lid.
• 3. Acceptance criteria in writing: what will the delivery be measured against? Agree before the project starts, not in the final week.
• 4. Changes regulated: what happens to wishes that come up during development — how are they priced and prioritised? Without a rule, scope grows and the deadline slips.

03Team and references (points 5–7)

• 5. Who actually develops? Employees, freelancers, subcontractors — and where? Ask specifically; the answer belongs in the quote. At appDev: a permanent, German-speaking team in Germany; we don't offer offshore.
• 6. Verifiable references: named projects of comparable size, ideally with a contact person you can call — not just a logo wall. What that can look like: our references.
• 7. Availability and language: a fixed project lead, response times, German or English — settle it up front, not in the first conflict.

04Technology and data protection (points 8–10)

• 8. Reasoned technology choice: why native, why cross-platform, why this framework? “That's how we always do it” is not a reason — the choice must follow from your requirements.
• 9. Hosting and GDPR: where do servers and data run (EU?), who is the processor, is there a data processing agreement? Non-negotiable with personal data. How we handle it: EU hosting and GDPR.
• 10. Handover capability: could another team take over the code? Indicators: documentation, tests, standard technologies instead of home-grown frameworks.

05Operation and the future (points 11–12)

• 11. Maintenance with a price: what do operation, OS updates and incident handling cost after launch — as a number in the quote, not as “we'll sort that out later”. A common industry rule of thumb is 15–20 % of the development cost per year.
• 12. Exit scenario: what happens if the provider is terminated or goes out of business? Code release, access, documentation — regulated before you need it.

06Comparing quotes: the small print

With two or three quotes on the table, the price alone rarely decides. Five places in the small print that can cost more than any price difference:

• Usage rights complete and transferable: not just “use”, but the right to modify and pass on the code — otherwise you can't switch later.
• Ownership of store account and domain: the App Store account, Google Play account and domains belong in your name. If the app runs through the provider's account, your customer relationship depends on their goodwill.
• Third-party licences and open source: which external libraries are inside, with which licence obligations and follow-up costs? A list belongs in the quote.
• Warranty in concrete terms: how long are defects fixed free of charge after acceptance, with what response time?
• Prices for later stages: at what rate are extensions billed later? A low entry price with expensive follow-up orders is a familiar pattern.

07After commissioning: the first two weeks

Whether the choice was right shows early. In the first two weeks you should see: a kickoff with everyone involved and clear responsibilities, the handover of access and test data, an agreed rhythm for interim versions — and the written acceptance criteria, if they are still missing. If two weeks pass with little tangible instead, that's not a slip, it's a pattern: raise it immediately, while changing course is still cheap.

08Five red flags

• A fixed-price commitment in the first conversation, before anyone has taken your requirements.
• The source code “remains with the provider” or costs extra.
• No nameable reference projects in your order of magnitude.
• Not a word about maintenance and operation in the quote.
• Pressure towards a full commission instead of a manageable first step (discovery, concept, MVP).