The final conversation before signing with an app development agency should test the parts of the relationship that will matter once delivery starts. At this stage, the proposal may look strong. The cost may fit your budget. The timeline may sound realistic. There are still some questions to ask an app development agency: who will write the code, who owns the code, how scope changes are handled, which data-processing terms apply, and what happens if the project starts to slip.
For Dutch and European companies, these questions are not administrative details. They affect GDPR obligations, contract enforceability, budget control, delivery continuity, and the ability to move the project to another partner if needed. If you are still shaping the full project from scratch, the complete mobile app development guide gives a broader planning view before you reach this final vendor conversation.
This article will give you 20 questions to ask before signing with an app development agency, with the red flag answers to watch for and the good answers you should expect from a professional partner.
TL;DR
Before signing with an app development agency, ask questions across five areas: team and delivery model, IP and exit rights, pricing and scope changes, GDPR and security, and references and escalation. The goal is not to interrogate the agency. The goal is to make the contract, team setup, and delivery risk visible before the first sprint starts.
The 20 questions are:
| Category | Questions to ask |
|---|---|
| Team and delivery model | Q1. Who will write the code? Q2. What seniority level is assigned? Q3. What happens if a key developer leaves? Q4. Is the team dedicated or shared? |
| IP, code ownership, and exit | Q5. Who owns the code? Q6. How do we transition to another agency? Q7. Which third-party libraries will be used? Q8. How is the codebase protected if the agency stops operating? |
| Contract, pricing, and scope changes | Q9. Is this fixed-scope or time-and-materials? Q10. How are new features added? Q11. What happens if milestones are delayed? Q12. Which costs are excluded? |
| GDPR, data, and security | Q13. Is a DPA ready? Q14. Where is project data stored? Q15. Who accesses production data? Q16. What happens after a data breach? |
| References and escalation | Q17. Can we speak to a similar Dutch or EU client? Q18. What happens if the project is behind schedule? Q19. How do we resolve technical disagreement? Q20. Which law governs the contract? |
If you are still comparing several vendors rather than preparing to sign with one or two finalists, start with how to evaluate and choose a mobile app development company. This article is for the final pre-contract conversation.
Why most Dutch companies skip questions to ask an app development agency and what it costs them
The questions that create the most protection are often the ones teams leave until too late. IP ownership sounds like legal detail until the client needs to move the codebase to another agency. A Data Processing Agreement sounds like paperwork until personal data enters the development environment. A governing-law clause sounds standard until a dispute has to be resolved outside the Netherlands.
The cost rarely appears on day one. It appears in Sprint 3, when the team discovers the “dedicated” developers are split across multiple clients. It appears when a feature change creates a dispute because the contract does not define what triggers a change order. It appears after launch, when the client cannot take over the codebase cleanly because handover rights were never made explicit.
A professional agency should not be defensive when you ask these questions. The answers show whether the agency has delivered serious client work before. The refusal to answer clearly is itself useful information.
How to use this list in the final pre-contract conversation
Use this list after you already have a preferred agency or one to two finalists. This is not the first vendor screening step. It is the final check before contract commitment. Set up a dedicated pre-contract Q&A call. Do not add these questions to the end of a pitch meeting. The agency should know the conversation is about delivery, contract terms, data, and risk. Share the five question categories in advance, not necessarily every question. A prepared agency will bring the right people into the call: delivery lead, technical lead, account owner, and someone who understands contract and data-processing terms. Bring your project brief and proposal to the conversation. If the brief is still vague, the answers will stay vague too. Before this stage, make sure you know what to include in your mobile app development brief so the agency can answer against a real scope, not an idea. Take notes on the answers. If you have two finalists, compare their answers after the call. A lower price can become less attractive when the agency cannot explain IP ownership, production access control, change orders, or breach notification.
Category 1: Team and delivery model
This category verifies who will actually build the product. The goal is to separate a clear delivery team from a shared resource pool hidden behind sales language.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| “Who will actually write the code for our project?” | The answer shows whether you are getting named people or a generic pool. | “Our development team will handle it.” No names, no roles, no seniority. | Names the tech lead or senior developer. Describes team composition and who reviews delivery quality. |
| “What seniority level are the developers assigned to our project?” | Junior-heavy teams can work, but only if senior oversight is clear. | “We only use senior developers.” This is often a sales answer unless names and roles support it. | States the ratio, such as one senior and two mid-level developers. Names who reviews code before delivery. |
| “What happens if a key developer leaves mid-project?” | This tests knowledge transfer and succession planning. | “That has never happened.” No replacement process. No documentation practice. | Describes handover, documentation, repository standards, and replacement expectations. |
| “Does our team work only on our project, or split time across multiple clients?” | This defines what “dedicated” means in practice. | “They are dedicated to your project,” but no written definition of availability or exclusivity. | States whether the team is exclusive, partially shared, or project-based. Any exceptions are written down. |
A shared specialist is not always a problem. For example, a DevOps or QA specialist may support more than one project. The problem is when the agency sells a dedicated model but assigns core developers across multiple clients without telling you. For Dutch companies working with an NL-VN delivery model, this question matters even more. The time-zone overlap can work well, but only when team availability and decision ownership are clear from the start.
Category 2: IP, code ownership, and project exit
This category protects the client if the relationship changes. A good contract should make exit possible without turning the project into a hostage situation.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| “Who owns the code at every stage of the project: during development and at handover?” | Ownership affects your ability to maintain, modify, or move the app later. | “You own the product at handover,” but the contract is unclear on source code, repositories, or reusable components. | The contract clearly states what the client owns, what the agency retains, and how source code is handed over. |
| “What is the process for moving the project to another agency if we change partners?” | A professional agency can explain exit without treating it as an insult. | “We would discuss that if it happens.” No handover process. Proprietary tooling creates lock-in. | Describes repository access, documentation, environment setup, handover support, and transition timing. |
| “Which third-party libraries and open-source components will you use, and what are the licence implications?” | Open-source licences can affect commercial use, redistribution, or derivative work. | “We use standard libraries, so it is fine.” No licence review. No component list. | States how libraries are selected, reviewed, and documented. Flags any restrictive licence before implementation. |
| “Is there a code escrow arrangement, or how is the codebase protected if the agency stops operating?” | Larger projects need continuity if the agency becomes unavailable. | “That will not happen.” No repository access outside the agency. | Offers client-owned repository access, regular code pushes, or an escrow option for larger contracts. |
Do not accept vague ownership language. “The app is yours” is not enough. You need clarity on source code, repositories, build scripts, documentation, design files, third-party components, and deployment access.
The goal is not to prepare for a bad relationship. The goal is to make sure the project can survive normal business changes.
Category 3: Contract, pricing model, and scope changes
This category checks how financial risk is handled. Many app projects do not fail because the first estimate was wrong. They fail because the contract did not define how change would be handled.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| Question | Why it matters | Red flag answer | Good answer |
| “If we add a feature during the project, what is the process and typical cost impact?” | Scope changes are normal. The process should not be improvised. | “We can usually fit in small changes.” No written impact assessment. | Written change request, impact estimate, approval step, and timeline update before implementation. |
| “What are the payment terms, and what happens if a milestone is delayed on your side?” | Payment terms should match delivery progress. | Monthly billing continues even when vendor-caused delays block delivery. | Milestones connect to accepted deliverables. Vendor-caused delay has a stated remedy or payment adjustment. |
| “Are there costs not included in this proposal, such as maintenance, hosting, App Store fees, third-party APIs, or support?” | Hidden costs change the real budget after signing. | “Those are standard costs you handle separately.” No estimate of excluded items. | Lists exclusions clearly and gives estimated annual running costs. |
Question 12 is the one many teams miss. The build price is not the full cost. Hosting, maintenance, support, analytics tools, third-party APIs, App Store accounts, security testing, and post-launch changes can increase the Year 1 budget. Use [hidden costs of mobile app development] to check which cost categories should be clarified before signing.
If you are close to signing with an app development agency, use the final conversation to clarify the points that affect delivery risk: team structure, scope changes, pricing model, DPA, SCCs, governing law, access control, escalation path, and post-handover ownership. Sunbytes can help you review these questions before you commit. Talk to Sunbytes before signing.
Category 4: GDPR, data processing, and security
This category is where Dutch and European procurement often needs more precision. If the app processes personal data, the agency relationship is not only a delivery relationship. It may also be a data-processing relationship.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| Question | Why it matters | Red flag answer | Good answer |
| “Do you have a Data Processing Agreement ready to sign, including SCCs if personal data is transferred outside the EU/EEA?” | Article 28 GDPR requires processing by a processor to be governed by a contract or other legal act. | “We will sort that out during the project.” No DPA ready before personal data is processed. | Has a DPA process ready before project start. Includes SCCs where non-EU/EEA transfer applies. |
| “Where is project data stored: EU-only, or mixed with non-EU storage?” | Data location affects privacy, procurement, and risk review. | Cannot name hosting regions or uses mixed regions without explanation. | Names the cloud provider and region. Can support EU-only storage where the project requires it. |
| “Who has access to production data during development, and how is access controlled?” | Developers should not have broad access by default. | “The whole team has access.” No access policy or review process. | Uses role-based access, least-privilege access, named approvers, and documented reviews. |
| “What is your incident response procedure if a data breach occurs during development, and when do you notify us?” | The client needs enough time to assess and notify the supervisory authority where required. | “We would contact you if something happens.” No timeline, no incident response process. | Has a written incident response process and commits to fast client notification after discovery. |
For Q13, the DPA is not a preference. Article 28 GDPR states that processing by a processor must be governed by a contract or other legal act that sets out the processing scope, duration, purpose, data types, data-subject categories, and obligations.
If personal data moves from the EU/EEA to a country outside the EU/EEA, ask whether Standard Contractual Clauses apply. The European Commission issued modernised SCCs in 2021 for transfers from EU/EEA controllers or processors to non-EU/EEA recipients that are not subject to the GDPR.
For Q16, Article 33 GDPR requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in risk to people’s rights and freedoms.
If your app will process personal data, use GDPR compliance requirements for mobile apps to understand the requirements before contract signing. ISO 27001 certification is also a useful signal, but it is not a substitute for specific answers. For example, ask how access control works in the project. ISO 27001:2022 Annex A includes access-control expectations such as role-based and least-privilege access.
Category 5: References, track record, and conflict resolution
This category tests how the agency behaves when the project is no longer in sales mode. Good references and clear escalation paths reveal how the agency handles pressure.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| “Can you introduce us to a Dutch or European client who ran a similar project in the past 18 months?” | A relevant reference checks whether the agency has delivered similar work recently. | Only offers written testimonials. Reference is old, unrelated, or outside your market context. | Provides one or two relevant references, subject to client permission and NDA limits. |
| “If the project is behind schedule by Sprint 4, who owns the delay and what is the remediation process?” | This tests accountability before the relationship is under pressure. | “Delays are usually caused by changing requirements.” Blames the client before work starts. | Separates client-caused and vendor-caused delays. States remediation steps and decision owners. |
| “If we disagree with your technical recommendation, how do we resolve it?” | The answer shows whether the agency acts as a partner or only a code supplier. | “We do what the client asks.” No challenge process. No risk documentation. | Explains the recommendation, documents the trade-off, and implements the final decision with clear risk notes. |
| “Which law governs this contract, and which court has jurisdiction for disputes?” | Governing law affects enforcement if the relationship breaks down. | Non-Dutch governing law by default, no jurisdiction clause, or dispute forum outside the expected procurement context. | For Dutch clients, the agency can discuss Dutch-law contracting and Dutch court jurisdiction where applicable. |
Question 19 is especially useful. You do not want an agency that ignores your input. You also do not want one that silently implements a technical decision it believes will create risk. A mature answer sounds like this: “We will document our recommendation, explain the consequences of the alternative, and let you make the final business decision. If you choose the higher-risk option, we record that decision.”
That answer protects both sides.
The 5 questions to ask an app development agency that Dutch companies most often forget to ask
Most teams remember to ask about cost, timeline, and case studies. The questions they skip are usually the ones that feel too legal, too operational, or too detailed for a sales process. The five most commonly missed questions are:
| Question | Why it gets missed | Why it matters |
|---|---|---|
| Q5. Who owns the code? | The proposal says “custom app,” so the client assumes ownership is clear. | Source code, repositories, libraries, and handover rights must be explicit. |
| Q13. Is a DPA ready? | Data-processing terms feel like legal paperwork. | For personal data processing, the DPA should be handled before work starts. |
| Q17. Can we speak to a similar Dutch or EU client? | Asking for a reference can feel uncomfortable. | A relevant reference tests delivery reality, not sales quality. |
| Q20. Which law governs the contract? | Legal clauses look like boilerplate. | Governing law affects enforcement, dispute handling, and procurement comfort. |
| Q4. Is the team dedicated or shared? | “Dedicated team” sounds self-explanatory. | The agency’s definition may not match yours unless it is written down. |
These questions are not signs of distrust. They are normal procurement hygiene for a project that may cost tens or hundreds of thousands of euros.
How Sunbytes answers pre-contract questions
A professional app development partner should treat due diligence as part of delivery discipline. The pre-contract conversation is where both sides make delivery expectations clear before the first sprint starts.
For Dutch and European clients, Sunbytes clarifies the practical questions before signing: who works on the project, how the delivery model is structured, how scope changes are handled, what data-processing terms apply, how security responsibilities are assigned, and what happens if the project needs escalation. Through Digital Transformation Solutions, Sunbytes supports mobile app development with delivery planning, engineering, QA/testing, maintenance, and support. The aim is to make the final pre-contract conversation specific enough that delivery starts with fewer assumptions.
Why Sunbytes
Sunbytes is a Dutch technology company with headquarters in the Netherlands and a delivery hub in Vietnam. With 15+ years operating in Vietnam, 300+ engagements delivered across 20+ countries, ISO 27001 certification, and delivery teams that can be set up in 2–4 weeks, Sunbytes helps Dutch and European companies clarify the contract, team, security, and delivery questions before development starts.
- Digital Transformation Solutions: We build and modernise digital products with senior engineering teams across custom development, QA/testing, maintenance, and support. For mobile app projects, this means the scope, architecture, team model, and delivery plan are clarified before execution begins.
- CyberSecurity Solutions: We reduce delivery risk through practical security services and compliance readiness. For app development, this supports the questions Dutch clients need answered before signing: data processing, access control, incident response, DPA/SCCs, and secure-by-design responsibilities.
- Accelerate Workforce Solutions: We help companies scale delivery capacity when growth demands more people than the internal team can provide alone. For mobile app projects, this can support dedicated team setup, recruitment, and workforce planning when long-term delivery capacity matters.
Bring your proposal, contract questions, delivery concerns, and security requirements into one focused conversation. Schedule a consultation with us to clarify team structure, scope-change risk, GDPR requirements, access control, escalation paths, and delivery ownership before you commit to an app development agency.
FAQs
The most important question is: “Who owns the code, repositories, documentation, and handover rights?” If the contract is unclear, you may struggle to maintain the app or move it to another partner later. Ownership should be written into the contract, not assumed from the proposal.
Yes, if the agency will process personal data on your behalf. Article 28 GDPR requires processor relationships to be governed by a contract or other legal act. For Dutch companies, this should be handled before personal data enters the development process.
Yes. A professional agency should expect reference checks before a serious contract is signed. The best reference is from a Dutch or European client with a similar project type, scope, or delivery model.
Ask whether they can work with your legal team’s DPA or a recognised Dutch processor-agreement template. The Dutch Data Protection Authority explains that processor agreements record the arrangements between controller and processor, and these agreements must fit AVG/GDPR requirements. Dutch legal providers such as ICTRecht also publish guidance on standard processor agreements in practice.
A good agency should be able to answer all 20, even if some answers need legal or delivery-team confirmation after the call. The red flag is not “we will confirm this in writing.” The red flag is avoiding the question, giving a sales answer, or treating normal due diligence as a problem.
Ask them before the contract is finalised. The answers should shape the contract, not sit outside it. If an answer matters to delivery risk, ownership, data processing, payment, or escalation, it should be reflected in the agreement or statement of work.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
