Table of Contents

• Q1: What does your discovery process look like?
• Q2: Who will actually build my product?
• Q3: How do you handle scope changes?
• Q4: What project management methodology do you use?
• Q5: What tech stack do you recommend, and why?
• Q6: Who owns the source code and IP?
• Q7: How is the project priced, and what triggers extra charges?
• Q8: Do you have experience building AI features into applications?
• Industry-Specific Considerations: FinTech, HealthTech, eCommerce
• Q9: How do you handle UK GDPR within your development process?
• Q10: What does your contract say about liability and dispute resolution?
• Q11: What is your approach to security and penetration testing?
• Q12: What are the payment milestones?
• Post-Engagement Governance: Handover, SLAs, and Knowledge Transfer
• Q13: What does post-launch support look like?
• Q14: Can you provide two client references from a similar sector?
• Q15: What would cause this project to fail?
• Green Flags vs Red Flags: The Full Comparison
• Frequently Asked Questions
• Conclusion

15 Questions You Must Ask a London App Developer Before Signing (2026 Checklist)

Signing a contract with a London app development agency is one of the highest-stakes vendor decisions a founder or technology leader makes. Get it right and you gain a committed build partner with skin in the game. Get it wrong and you inherit months of delays, ownership disputes, and a codebase you cannot maintain. The difference, in almost every case, comes down to what was asked before the contract was signed.
London has no shortage of capable agencies. It also has no shortage of outfits that win engagements on polished decks and underdeliver on execution. Knowing which top software and AI partners in London genuinely earn that designation requires asking structured, specific questions rather than the soft warm-up questions that agency sales teams are trained to deflect. This checklist covers all fifteen.
These questions are sequenced by theme: starting with discovery and process, moving through IP, legal, and compliance, and finishing with the governance and risk questions that separate sophisticated buyers from first-time ones. McKinsey research shows that roughly 70% of large technology projects run over budget or over time. The vendor selection conversation is where that risk is either mitigated or embedded.

Key Takeaways

• IP ownership does not transfer automatically on payment under UK law. A written assignment clause is mandatory.
• A formal discovery phase before development is the single most reliable predictor of a project delivered on scope and budget.
• London agency day rates range from £600 to £900 for senior teams. Understand what is included before comparing quotes.
• UK GDPR requires a written Data Processing Agreement if the agency accesses personal data during development.
• Reputable agencies welcome difficult questions. Evasion on IP, references, or team composition is itself a diagnostic signal.
• Post-launch support costs typically run 15 to 20% of the original build cost per year. Budget for this before signing.
• The questions that most buyers skip  covering tech stack rationale, AI capability, and handover governance — are the ones most likely to determine long-term project success.

Q1: What Does Your Discovery Process Look Like Before a Line of Code Is Written?

A structured discovery phase  typically two to four weeks  is the clearest indicator of a professional agency. It should produce a technical specification, wireframes or user flows, a risk register, and a realistic timeline. Agencies that skip discovery and move straight to quoting are pricing a project they do not yet understand.
The discovery question is the most important one on this list. It surfaces everything that matters: whether the agency thinks strategically, whether it listens before it sells, and whether it has a process for translating a business problem into a technical specification.
Strong agencies will describe a discovery phase as a paid, time-boxed engagement typically priced between £3,000 and £10,000 depending on project complexity. Agencies that offer free discovery are either absorbing that cost into the build price or skipping it entirely. Neither is ideal.
The discovery output should include: a technical scope document, user personas and journey maps, wireframes or low-fidelity prototypes, a considered tech stack recommendation with rationale, a project timeline with milestones, and a risk register flagging the project’s most likely failure modes. If an agency cannot describe what their discovery produces, that is an answer in itself.
What to listen for: Specific phases, named deliverables, a timeline, and acknowledgment that discovery findings can change the original brief. Vague answers like “we get to know your business” or “we move fast” are warning signals.

Q2: Who Will Actually Build My Product, and Can I Meet the Team?

The team presented during the sales process and the team assigned to your project are often different people. Asking to meet your actual developers, designers, and project manager before signing is not an unusual request. Any resistance to this ask warrants scrutiny.
Bait-and-switch team composition is one of the most common sources of friction in agency engagements. A senior architect presents the pitch, and the work is delivered by junior contractors or an offshore team you were never told about. This is not inherently wrong, but it must be disclosed and contracted.
Ask specifically: who is the project manager, who are the lead developers (by name), are any parts of the build being subcontracted, and what percentage of the work is delivered onshore versus offshore? A strong agency should be able to provide the names and LinkedIn profiles of the core team within 48 hours of the request.
For projects in regulated sectors, team composition is a contractual matter. Financial Conduct Authority red flags when hiring a software agency in the UK frequently include undisclosed subcontracting where audit trails become impossible to maintain. Always request a named team as a contractual deliverable, not a verbal assurance.
A team that includes UI/UX designers, frontend and backend developers, a QA engineer, and a dedicated project manager is the minimum staffing profile for a serious engagement. Insist on meeting the delivery team before contracts are signed, not after.

Q3: How Do You Handle Scope Changes During a Project?

Scope change management is where projects become expensive and relationships deteriorate. The agency’s answer should describe a formal change control process: written change requests, documented impact assessments covering time and cost, client approval before work proceeds, and a defined timeline for processing requests.
Every non-trivial software project involves scope changes. The question is not whether changes will happen but how they are managed. Agencies with no formal change control process are likely to either absorb changes silently until resentment builds, or raise surprise invoices that the client feels blindsided by.
The answer to look for: a named change control procedure, a documented process for raising, pricing, and approving changes, a definition of what constitutes a scope change versus a bug fix, and a maximum response time for change request assessments. Ask agencies to walk through a real example of a scope change from a previous project and how it was handled end to end.
Also ask: what is the difference between a bug and a feature addition in your contracts? Many disputes arise precisely because this distinction is not defined. A bug is a deviation from the agreed specification. A feature addition is anything not in that specification, however reasonable it seems at the time.

Q4: What Project Management Methodology Do You Use, and How Will We Communicate?

Agile with two-week sprints is the dominant methodology for custom app development in London. Ask for the specifics: daily standups or weekly check-ins, sprint reviews with client participation, retrospectives, and the tools used for task tracking and communication. Methodology should match your project’s complexity and your team’s availability to be involved.
Methodology questions reveal how organised the agency is and how much client involvement is expected. A well-run agency will have a consistent answer that aligns with how they work in practice. An agency that says “we are flexible, we work however suits you” is often telling you they have no strong process.
Specific questions to ask within this category: Which project management tool do you use (Jira, Linear, Notion, Monday.com)? How frequently are sprint reviews scheduled, and is client attendance expected? Who is the primary point of contact for day-to-day questions? How are blockers escalated? What is the SLA for responding to client queries during the project?
For London engagements, the communication norms are typically higher than for offshore teams. Clients working with leading London development studios should expect weekly written progress updates, fortnightly sprint reviews with a shared board, and a named project manager reachable within a few hours by phone or message during UK business hours.

Q5: What Tech Stack Do You Recommend for My Project, and Why?

A credible agency recommends a tech stack based on your project requirements, team composition, scalability targets, and maintenance needs. It does not recommend based on the tools its developers happen to know best. Ask for the rationale behind every recommendation, and probe whether cross-platform or native mobile development is the right choice for your audience and budget.
Tech stack decisions made at the start of a project shape every engineering decision that follows. A stack chosen for the agency’s convenience rather than your business requirements creates technical debt that can cost ten times more to unwind than the initial saving justified.
The stack question should cover: frontend framework (React, Vue, Angular, or native mobile), backend language and framework (Node.js, Python/Django, Laravel, Ruby on Rails, Go), database approach (relational, NoSQL, time-series), hosting environment (AWS, GCP, Azure, or a managed provider), and for mobile specifically, whether the recommendation is Flutter, React Native, or fully native iOS/Android.
Understanding how to choose the right tech stack for your UK project is a strategic decision, not a technical one. The agency should be able to explain the trade-offs: cross-platform tools like Flutter reduce build cost by 30 to 40% but carry limitations for certain hardware features; native development costs more but delivers optimal performance for data-intensive or hardware-dependent applications.
Also ask: what open-source libraries will be used, are any components subject to copyleft licences, and will you provide a Software Bill of Materials (SBOM) at handover? Requiring SBOM documentation ensures no open-source components introduce licence obligations that restrict the client’s use of the final product.

Q6: Who Owns the Source Code and Intellectual Property Once the Project Is Complete?

There is only one acceptable answer: the client owns all custom code and intellectual property, confirmed by a written assignment clause in the contract. Under the UK Copyright, Designs and Patents Act 1988, a contractor retains copyright unless an explicit written assignment transfers it to the client. Payment alone does not transfer ownership.
IP ownership is the question that separates careful buyers from those who discover a costly problem six months after launch. Under UK law, if a developer is engaged as a contractor (not an employee), they retain copyright in any code they produce unless the contract includes an explicit written assignment. This is one of the most misunderstood aspects of UK software contracting.
The contract should specify: all custom code produced for the engagement is assigned to the client upon payment; any reusable components or frameworks retained by the agency are specifically identified and a perpetual licence to use them is granted; third-party components are listed with their licence types; and the agency warrants that the deliverable does not infringe any third-party IP.
Ask specifically: does your standard contract include a present IP assignment or a future promise? The difference matters. A present assignment transfers rights now. A future promise is an undertaking to assign at a later date, which carries enforcement risk. Data collected through the application — including user data and behavioural analytics — must be clearly designated as belonging to the client, not the agency.

Q7: How Is the Project Priced, and What Triggers Additional Charges?

London app development agencies typically offer fixed-price contracts, time-and-materials billing, or hybrid models. Each has trade-offs. Fixed-price protects budget but constrains flexibility. Time-and-materials allows iteration but requires active budget monitoring. Know which model applies, what is explicitly excluded from the quoted price, and what the change request rate is before signing.
In 2026, London senior agency day rates range from £600 to £900 per day, with central London agencies charging a 15 to 25% premium over regional UK studios. A standard business app typically costs £30,000 to £80,000, while a complex multi-role product runs £70,000 to £150,000.
Ask the following price-related questions: Is this quote fixed or indicative? What assumptions underlie the estimate? What happens if the scope grows by 20%? Are design, QA, and project management included in the quoted price or billed separately? What is the rate for change requests after contract signature? Is the first bug-fix period (typically 30 to 90 days post-launch) included?
Also ask about payment milestone structure. Standard practice in the UK is approximately 25 to 33% on signing, 25 to 33% at one or more mid-project milestones, and the remainder on completion. Any agency requesting 50% or more upfront before substantive work has been delivered warrants scrutiny. Large upfront payment demands are one of the most reliable warning signals in agency procurement.

Q8: Do You Have Experience Building AI or Machine Learning Features Into Applications?

AI capability is now a practical requirement for many applications, not an optional enhancement. A London agency building a product in 2026 should have direct experience integrating LLM APIs, building recommendation engines, or deploying predictive features. Ask for a specific example, not a general statement of capability.
AI feature integration is no longer the exclusive domain of deep-tech startups. Business applications across sectors now include conversational interfaces, intelligent search, anomaly detection, content generation, and predictive analytics. An agency without hands-on AI integration experience will struggle to advise on model selection, prompt engineering, latency trade-offs, or cost management for inference at scale.
Ask specifically: have you integrated OpenAI, Anthropic Claude, Google Gemini, or open-source LLMs into a production application? What was the use case? How did you handle hallucination risk and response validation? Do you have experience with retrieval-augmented generation (RAG) architectures? Can you advise on fine-tuning versus prompt engineering for our use case?
For AI-adjacent questions on tooling and model selection, working with a studio that maintains active relationships among the recognised AI development partners in London provides access to practitioner knowledge that generalist agencies cannot match.

Industry-Specific Considerations: What to Ask for FinTech, HealthTech, and eCommerce Projects

The fifteen questions in this checklist apply universally. But regulated industries require additional interrogation that goes beyond general agency vetting. FinTech, HealthTech, and eCommerce each have sector-specific compliance and architecture requirements that should shape your evaluation before signing.

FinTech

For financial applications covering payments, lending, investment, or insurance, ask whether the agency has worked with FCA-regulated clients. The Financial Conduct Authority requires documented development processes, audit trails, and evidence of appropriate governance. An agency without FCA-adjacent experience will not understand why a feature cannot simply be “shipped and fixed later.”
Ask specifically: have you built a product that underwent FCA regulatory review? Do you have experience with Open Banking APIs (PSD2)? How do you handle financial data residency requirements? Do your contracts include the security testing provisions expected by financial regulators?

HealthTech

HealthTech applications handling patient data or clinical workflows are subject to NHS Digital standards, DSPT (Data Security and Protection Toolkit) requirements, and, for medical devices, MHRA regulations. Ask whether the agency has CE or UKCA marking experience for software as a medical device. Ask how they handle clinical data security and whether they have worked with NHS procurement processes.

eCommerce

For eCommerce platforms, the critical questions concern PCI DSS compliance for payment processing, integration experience with major platforms (Shopify, Magento, WooCommerce, or headless commerce), mobile performance optimisation, and the agency’s experience building for peak traffic scenarios. Ask: have you built an application that survived a significant traffic spike, and what architecture decisions supported that?

Q9: How Do You Handle Data Protection and UK GDPR Compliance Within Your Development Process?

If the development agency accesses or processes personal data during the engagement, a written Data Processing Agreement is mandatory under Article 28 of UK GDPR and the Data Protection Act 2018. This is not optional. Any agency unaware of this requirement, or unwilling to sign a DPA, presents a compliance risk that the client’s business will bear.
Data protection obligations extend to the vendor relationship, not just the finished product. If developers have access to production data, test data containing real personal information, or user account records during QA, the engagement is governed by UK GDPR as a controller-processor relationship. The contract must cover the purpose and duration of processing, the nature of personal data, the obligations of the processor, and provisions for deletion or return of data at contract end.
Beyond the DPA, ask: do you use anonymised or synthetic data for development and testing? What is your data breach notification process, and what is the response time? Are any sub-processors (cloud providers, monitoring tools, third-party APIs) involved in the engagement that will process personal data? Have those sub-processors been assessed and documented? Sub-processor chains are one of the most commonly overlooked UK GDPR compliance risks in software development projects.
If the agency’s developers are based outside the UK, ask how data transfers are managed. For developers in countries without UK adequacy status, Standard Contractual Clauses or equivalent transfer mechanisms are required under the Data Protection Act 2018.

Q10: What Does Your Contract Say About Liability, Indemnity, and Dispute Resolution?

Standard agency contracts typically cap liability at the value of the contract, exclude consequential loss, and specify English law and jurisdiction. Understand the cap before signing: if the agency’s error causes you £500,000 in downstream losses but their liability is capped at the £80,000 contract value, professional indemnity insurance held by the agency is your only additional recourse.
Contract review by a commercial solicitor before signing is not a sign of distrust. It is standard commercial practice for any engagement above £20,000. Specific areas to examine: the liability cap and whether it applies per incident or in aggregate; the indemnity provisions covering third-party IP claims; the warranty period for bug fixes post-launch; the dispute resolution mechanism (mediation before litigation is preferable); and the governing law and jurisdiction clause.
Also ask whether the agency carries professional indemnity insurance and what the coverage level is. For a £100,000 project, a minimum of £1 million in professional indemnity coverage is a reasonable expectation. Request a copy of the agency’s current insurance certificate before contract execution.
Understanding the contractual red flags when hiring a software agency in the UK is as important as evaluating technical capability. Agencies that resist standard liability and indemnity terms, or whose contracts contain unusual carve-outs in the IP assignment clause, are communicating something important about how they manage disputes.

Q11: What Is Your Approach to Security Testing and Penetration Testing?

Security should be built into the development process, not bolted on at the end. Ask whether the agency follows secure coding standards (OWASP Top 10 is the baseline), whether automated security scanning is part of the CI/CD pipeline, and whether independent penetration testing is included in the project scope or available as an add-on.
Application security failures are expensive. The average cost of a data breach in the UK reached £3.58 million in 2024. Security testing is not a post-launch luxury. It is a pre-launch requirement for any application handling sensitive data, financial transactions, or personal information.
Ask specifically: do you follow OWASP Top 10 guidelines in your development process? Is static application security testing (SAST) automated in your pipeline? Do you conduct dynamic testing (DAST) before release? Do you engage an independent third party for penetration testing, or is this in-house? For applications that will be FCA-regulated or NHS-connected, independent pen testing by a CREST-certified provider is typically required.
Also ask about dependency management: how do you monitor for known vulnerabilities in third-party packages post-launch? The answer should reference tools like Dependabot, Snyk, or equivalent, not a manual review process. Automated dependency scanning is a baseline security practice recommended by NCSC for all UK commercial software.

Q12: What Are the Payment Milestones, and What Happens If a Milestone Is Missed?

Payment milestones tied to deliverable acceptance protect both parties. Understand what constitutes milestone completion, who has the authority to sign off on each milestone, what the process is for disputing a milestone claim, and what happens contractually if the agency misses a milestone date. Penalties for missed milestones should be proportional and defined, not left to negotiation at the time of dispute.
Payment milestone design is one of the most consequential elements of a software development contract. Milestones that are vaguely defined (“design complete”, “backend ready”) create disputes. Milestones tied to specific, verifiable deliverables with documented acceptance criteria (“user authentication system deployed to staging environment, all acceptance tests passing”) resolve disputes before they arise.
The typical milestone structure for a London agency engagement runs: 25 to 33% on contract signature (covering discovery and setup), one or two mid-project milestone payments tied to specific delivery stages, and the remaining balance on project sign-off and handover. For longer projects (six months or more), monthly billing against an agreed schedule may be appropriate.
Ask specifically: what are the agreed acceptance criteria for each milestone? Who on our side is authorised to approve milestone sign-off? What is the cure period if a milestone delivery does not meet the acceptance criteria? What happens if we dispute a milestone claim: is work paused, continued, or subject to escrow? These questions are uncomfortable to ask but they define the entire risk profile of the engagement.

Post-Engagement Governance: Handover, Knowledge Transfer, and Ongoing Support

The end of the initial build is not the end of the relationship with the technology. Post-engagement governance covers how the agency transitions the codebase, documentation, and operational knowledge to the client’s team or a successor agency. Poor handover is one of the most common and costly failures in software procurement, and it must be contractually specified before work begins.
Handover requirements should be defined in the original contract, not negotiated as an afterthought when the project completes. The minimum handover package for any serious engagement should include: full source code committed to a client-owned repository; environment variables and credentials documented and transferred securely; infrastructure configuration documented (Infrastructure as Code preferred); architectural decision records (ADRs) explaining why key decisions were made; a dependency manifest and SBOM; and a minimum 30-day post-launch support window with a named point of contact.
For projects involving AI components, additional handover considerations apply: model selection rationale, prompt engineering documentation, API key management procedures, cost monitoring setup, and guidance on model version management as underlying models are updated by providers.
Ask any prospective agency to share a sample handover package from a previous engagement (with client permission or anonymised). If they cannot produce one, or if the concept of a handover package is new to them, that is a significant governance gap. The handover question is among the most commonly neglected in client vendor assessments, and among the most expensive when it goes wrong.

Q13: What Does Post-Launch Support Look Like, and What Is Covered in the SLA?

Post-launch support is where many agency relationships break down. The initial engagement ends, the team disbands, and the client is left with a product that needs maintenance, bug fixes, and feature additions but no committed partner to deliver them. Understand the support model — whether retainer, ad hoc, or dedicated team — and the response time SLA for critical, high, and medium-severity issues before signing the build contract.
Most UK agencies charge 15 to 20% of the original build cost per year for ongoing maintenance and support. This is the market standard. Budget for this cost before committing to the build: a £60,000 application carries £9,000 to £12,000 in annual maintenance costs at market rates.
Ask specifically: is there a defined warranty period post-launch during which bugs are fixed at no additional charge, and how long is it? What is the response time SLA for a critical production issue (typically P1 = under two hours)? Is monitoring and alerting included in the retainer? Are app store updates for new iOS and Android OS versions covered? How is support priced: fixed retainer, time-and-materials, or pre-purchased hours?
Also ask about team continuity. One of the most disruptive post-launch events is the departure of the developer who built the application. Ask whether the agency has a knowledge-sharing policy that prevents any single developer from being the sole holder of critical knowledge, and whether code review practices ensure that multiple team members understand the codebase.

Q14: Can You Provide References from at Least Two Clients in a Similar Sector?

Client references are the most reliable validation signal available. Ask for two or three references from clients with similar project types, budgets, and sectors. Contact those references directly, ask open-ended questions, and listen for what is not said as much as what is. An agency that hesitates to provide references, or offers only written testimonials instead of direct introductions, is communicating something significant.
Written case studies and portfolio entries are marketing materials. A direct conversation with a past client is due diligence. The distinction matters because agencies curate their portfolio for maximum appeal and minimise or omit projects that were difficult, delayed, or disputed. Only a direct reference call surfaces that context.
Questions to ask references: Was the project delivered on time and on budget? How was scope change handled? Were there any issues with the team composition during the project? How was the handover process managed? Would you hire this agency again for a similar project, and if not, why?
When evaluating which studios rank among the top software and AI partners in London, client reference quality is among the most reliable differentiators. Agencies with genuinely satisfied clients are proud to connect prospective clients with them. Agencies that redirect every reference request to a testimonials page are managing perception rather than sharing evidence.
Ask for at least two references within the same budget range as your project, since an agency’s experience at the £30,000 level does not automatically translate to competence at £150,000.

Q15: What Would Cause This Project to Fail, and How Do You Mitigate Those Risks?

This is the question most buyers never ask, and it is the most revealing one on this list. A confident, experienced agency will answer it without hesitation: they have seen projects fail and they know the patterns. Vague answers, deflection, or pure optimism are the responses of an agency that either lacks experience or is unwilling to have an honest conversation before the contract is signed.
Every software project has a set of specific, predictable failure modes. For most application builds, they cluster around: unclear requirements that shift during development; insufficient client availability for feedback and approvals; underestimated technical complexity, particularly in integrations; team turnover on the agency side; and budget exhaustion before the product reaches a shippable state.
A strong agency will identify the specific risks for your project. They might say: “The integration with your existing ERP system is the highest risk on this project because the API documentation is incomplete. We need a two-week investigation sprint before we can price that component with confidence.” That is the response of a partner. “We’ll cross that bridge when we come to it” is the response of a vendor.
Ask the agency to rank the top three risks for your specific project and describe the mitigation for each. Ask whether they have failed to deliver a project on time or on budget in the past, and what they learned from it. Understanding the red flags when hiring a software agency in the UK includes recognising when an agency’s inability to discuss failure is itself a warning signal.
Agencies that answer this question honestly, specifically, and with a clear mitigation plan for each risk are the ones most likely to deliver. Transparency before the contract is the strongest predictor of transparency during it.

Green Flags vs Red Flags: The Full Agency Evaluation at a Glance

The 15 questions above generate a body of evidence about an agency’s capability, process, and commercial approach. The key signals across each evaluation dimension are summarised below.

• Discovery Process — Green Flag: Paid, time-boxed discovery with named deliverables (spec, wireframes, risk register).Red Flag: No discovery phase; immediate quoting from a brief or RFP document alone.

• Team Transparency — Green Flag: Named developers and PM provided before contract; subcontracting disclosed. Red Flag: Sales team presents but delivery team unknown; reluctance to name individuals.
• Scope Change Management — Green Flag: Documented change control process with written approvals and pricing before work. Red Flag: Verbal agreement on changes; surprise invoices; or all changes absorbed silently.
• IP Ownership — Green Flag: Present written IP assignment in standard contract; SBOM included at handover. Red Flag: Future promise to assign; vague clause; reusable components not identified.
• Pricing Transparency — Green Flag: Clear inclusions and exclusions; change request rate stated; milestone structure defined. Red Flag: Indicative quote with large assumptions; milestones undefined; change rate not stated.
• Payment Structure — Green Flag: 25 to 33% upfront; milestone-tied installments; balance on completion. Red Flag: 50% or more upfront; payment not tied to deliverables; unclear retention terms.
• Tech Stack Rationale — Green Flag: Stack recommended based on project requirements with documented trade-off analysis. Red Flag: Same stack recommended for every client; no articulation of trade-offs.
• UK GDPR / Data Protection — Green Flag: DPA signed as standard; anonymised test data; sub-processors documented. Red Flag: Unfamiliar with DPA requirement; uses production data for testing without controls.
• Security Practices — Green Flag: OWASP compliance; automated SAST in pipeline; independent pen testing available. Red Flag: Security tested manually at launch only; no automated scanning; no pen testing process.
• Contract (Liability / Indemnity) — Green Flag: Clear liability cap; professional indemnity insurance confirmed; dispute resolution defined. Red Flag: No liability cap; IP warranty absent; all disputes defaulted to litigation.
• Post-Launch Support — Green Flag: Defined warranty period; P1 SLA under two hours; retainer pricing clearly stated. Red Flag: Support discussed at project end; no SLA; ad hoc only at undefined rates.
• References — Green Flag: Direct client introductions offered promptly; sector-relevant references available. Red Flag: Written testimonials only; reference requests delayed or redirected; NDAs cited.
• Risk Honesty — Green Flag: Project-specific risks identified; mitigation plans articulated; past challenges discussed. Red Flag: Pure optimism; no risk register; reluctance to discuss previous project difficulties.
• Handover Governance — Green Flag: Handover package defined in contract; client-owned repo; ADRs and documentation included. Red Flag: Handover discussed at project end; undocumented codebase; no credential transfer plan.
• AI Capability — Green Flag: Named production AI integrations; experience with LLM APIs, RAG, prompt engineering. Red Flag: General statement of AI interest; no deployed AI features; inability to discuss trade-offs.

Frequently Asked Questions

How many questions should you ask a London app developer before signing?

A minimum of ten to fifteen structured questions covering process, team, IP ownership, pricing, legal protections, and post-launch support is recommended for any engagement above £20,000. For projects in regulated sectors such as FinTech or HealthTech, add sector-specific compliance questions on top of the core checklist before committing.

Who owns the app code after a London agency builds it?

Under the UK Copyright, Designs and Patents Act 1988, a contractor (not an employee) retains copyright in the code they write unless the contract contains an explicit written IP assignment transferring those rights to the client. Payment alone does not transfer ownership. Always have a solicitor confirm that a present assignment is included in the agreement before signing.

What is a fair payment structure for a London app development project?

Standard payment structure for a London agency engagement is approximately 25 to 33% on signing, 25 to 33% at one or more agreed delivery milestones, and the final 25 to 33% on project completion and sign-off. Any agency requesting 50% or more upfront before meaningful work has begun warrants scrutiny and a detailed explanation of how that payment will be applied to specific deliverables.

Does a London app development agency need to comply with UK GDPR?

Yes. If the development agency accesses or processes personal data on behalf of the client, a written Data Processing Agreement is mandatory under Article 28 of UK GDPR and the Data Protection Act 2018. The agreement must specify the scope of processing, security obligations, sub-processor rules, and end-of-contract data deletion or return requirements. Failure to have a DPA in place exposes the controller (the client’s business) to ICO enforcement risk.

What are the biggest red flags when evaluating a London app development agency?

The most significant red flags include: refusing to provide verifiable direct client references; demanding more than 50% payment upfront; no formal discovery or scoping phase before quoting; vague or unsigned contracts; inability to name the specific developers assigned to the project; no defined process for handling scope changes; and unwillingness to discuss previous project challenges. Any one of these signals warrants either a renegotiation or a withdrawal from the process.

Conclusion: The Questions That Protect Your Investment

The London app development market is deep, competitive, and uneven. Capability varies enormously between the top studios and those who pitch with equal confidence. The fifteen questions in this checklist are not a bureaucratic hurdle. They are the minimum standard for a commercially responsible vendor selection process.
The questions that most buyers skip are the ones that define outcomes: what happens to the IP when the project ends, how scope changes are managed, what the agency’s project-specific risk register looks like, and whether the post-launch support model actually sustains the product over the years that follow. Asking these questions before signing is not a sign of mistrust. It is the professional standard that serious agencies welcome and underprepared ones struggle with.
The best agencies will answer every question on this list clearly, specifically, and without hesitation. They have structured processes, experienced teams, and a track record they are willing to share. Those are the studios worth signing with.
For founders and technology leaders evaluating technical decisions before committing to a UK development partner, the time invested in structured vendor evaluation before signing always returns more value than the time spent resolving avoidable problems after the contract is live.