Het laatste gesprek voordat je tekent met een app development agency moet de onderdelen van de samenwerking testen die belangrijk worden zodra delivery start. In deze fase kan de proposal sterk lijken. De kosten kunnen binnen je budget passen. De timeline kan realistisch klinken. Wat nog onduidelijk is, is vaak belangrijker: wie schrijft de code, wie is eigenaar van de code, hoe worden scope changes afgehandeld, welke data-processing terms gelden en wat gebeurt er als het project begint uit te lopen?
Voor Nederlandse en Europese bedrijven zijn dit geen administratieve details. Ze beïnvloeden GDPR/AVG-verplichtingen, afdwingbaarheid van het contract, budgetcontrole, deliverycontinuïteit en de mogelijkheid om het project later naar een andere partner over te dragen indien nodig. Als je het volledige project nog vanaf nul vormgeeft, biedt de complete mobile app development guide een breder planningsperspectief voordat je dit laatste vendorgesprek bereikt.
Dit artikel geeft je 20 vragen die je moet stellen voordat je tekent met een app development agency, inclusief red flag-antwoorden om op te letten en goede antwoorden die je van een professionele partner mag verwachten.
TL;DR
Voordat je tekent met een app development agency, stel je vragen binnen vijf gebieden: team en deliverymodel, IP en exitrechten, pricing en scope changes, GDPR/AVG en security, en referenties en escalatie. Het doel is niet om de agency te ondervragen. Het doel is om het contract, de teamsetup en deliveryrisico’s zichtbaar te maken voordat de eerste sprint start.
De 20 vragen zijn:
| 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? |
Als je nog meerdere vendors vergelijkt in plaats van je voor te bereiden om met één of twee finalisten te tekenen, begin dan met how to evaluate and choose a mobile app development company. Dit artikel is bedoeld voor het laatste pre-contractgesprek.
Waarom de meeste Nederlandse bedrijven deze vragen overslaan en wat het ze kost
De vragen die de meeste bescherming bieden, zijn vaak precies de vragen die teams te laat stellen.
IP ownership klinkt als een juridisch detail totdat de klant de codebase naar een andere agency moet verplaatsen. Een Data Processing Agreement klinkt als papierwerk totdat persoonsgegevens in de developmentomgeving terechtkomen. Een governing-law clause klinkt standaard totdat een geschil buiten Nederland moet worden opgelost.
De kosten verschijnen zelden op dag één. Ze verschijnen in Sprint 3, wanneer het team ontdekt dat de “dedicated” developers over meerdere klanten verdeeld zijn. Ze verschijnen wanneer een feature change tot discussie leidt omdat het contract niet definieert wat een change order triggert. Ze verschijnen na launch, wanneer de klant de codebase niet netjes kan overnemen omdat handover rights nooit expliciet zijn gemaakt.
Een professionele agency hoort niet defensief te reageren wanneer je deze vragen stelt. De antwoorden laten zien of de agency eerder serieus klantwerk heeft geleverd. Een weigering om duidelijk te antwoorden is op zichzelf nuttige informatie.
Hoe je deze lijst gebruikt in het laatste pre-contractgesprek
Gebruik deze lijst nadat je al een voorkeursagency of één tot twee finalisten hebt. Dit is niet de eerste vendor screening step. Dit is de laatste check vóór contract commitment.
Plan een aparte pre-contract Q&A-call. Voeg deze vragen niet toe aan het einde van een pitchmeeting. De agency moet weten dat het gesprek gaat over delivery, contract terms, data en risico.
Deel de vijf vraagcategorieën van tevoren, niet per se elke vraag. Een voorbereide agency brengt de juiste mensen mee naar het gesprek: delivery lead, technical lead, account owner en iemand die contract- en data-processing terms begrijpt.
Neem je project brief en proposal mee naar het gesprek. Als de brief nog vaag is, blijven de antwoorden ook vaag. Zorg vóór deze fase dat je weet [what to include in your mobile app development brief], zodat de agency kan antwoorden op basis van een echte scope, niet alleen een idee.
Maak notities van de antwoorden. Als je twee finalisten hebt, vergelijk hun antwoorden na de call. Een lagere prijs kan minder aantrekkelijk worden wanneer de agency IP ownership, production access control, change orders of breach notification niet kan uitleggen.
Category 1: Team and delivery model
Deze categorie verifieert wie het product daadwerkelijk gaat bouwen. Het doel is om een duidelijke deliveryteamsetup te onderscheiden van een gedeelde resource pool die achter salestaal verborgen zit.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| “Who will actually write the code for our project?” | Het antwoord laat zien of je named people krijgt of een generieke pool. | “Our development team will handle it.” Geen namen, geen rollen, geen senioriteit. | Noemt de tech lead of senior developer. Beschrijft team composition en wie delivery quality reviewt. |
| “What seniority level are the developers assigned to our project?” | Junior-heavy teams kunnen werken, maar alleen als senior oversight duidelijk is. | “We only use senior developers.” Dit is vaak een salesantwoord tenzij namen en rollen het ondersteunen. | Geeft de verhouding aan, bijvoorbeeld één senior en twee mid-level developers. Noemt wie code reviewt vóór delivery. |
| “What happens if a key developer leaves mid-project?” | Dit test knowledge transfer en succession planning. | “That has never happened.” Geen replacement process. Geen documentation practice. | Beschrijft handover, documentatie, repository standards en replacement expectations. |
| “Does our team work only on our project, or split time across multiple clients?” | Dit definieert wat “dedicated” in de praktijk betekent. | “They are dedicated to your project,” maar zonder schriftelijke definitie van availability of exclusivity. | Geeft aan of het team exclusief, deels gedeeld of project-based is. Eventuele uitzonderingen worden schriftelijk vastgelegd. |
Een shared specialist is niet altijd een probleem. Een DevOps- of QA-specialist kan bijvoorbeeld meer dan één project ondersteunen. Het probleem ontstaat wanneer de agency een dedicated model verkoopt, maar core developers over meerdere klanten verdeelt zonder dit te melden.
Voor Nederlandse bedrijven die werken met een NL-VN deliverymodel is deze vraag nog belangrijker. De timezone overlap kan goed werken, maar alleen wanneer team availability en decision ownership vanaf het begin duidelijk zijn.
Category 2: IP, code ownership, and project exit
Deze categorie beschermt de klant als de relatie verandert. Een goed contract moet exit mogelijk maken zonder dat het project in een gijzelsituatie terechtkomt.
| 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 beïnvloedt je vermogen om de app later te onderhouden, wijzigen of verplaatsen. | “You own the product at handover,” maar het contract is onduidelijk over source code, repositories of reusable components. | Het contract vermeldt duidelijk wat de klant ownet, wat de agency behoudt en hoe source code wordt overgedragen. |
| “What is the process for moving the project to another agency if we change partners?” | Een professionele agency kan exit uitleggen zonder het als belediging te behandelen. | “We would discuss that if it happens.” Geen handover process. Proprietary tooling creëert lock-in. | Beschrijft repository access, documentatie, environment setup, handover support en transition timing. |
| “Which third-party libraries and open-source components will you use, and what are the licence implications?” | Open-source licences kunnen impact hebben op commercial use, redistribution of derivative work. | “We use standard libraries, so it is fine.” Geen licence review. Geen component list. | Geeft aan hoe libraries worden geselecteerd, gereviewd en gedocumenteerd. Flagged restrictive licences vóór implementation. |
| “Is there a code escrow arrangement, or how is the codebase protected if the agency stops operating?” | Grotere projecten hebben continuïteit nodig als de agency niet meer beschikbaar is. | “That will not happen.” Geen repository access buiten de agency. | Biedt client-owned repository access, regelmatige code pushes of een escrow option voor grotere contracten. |
Accepteer geen vage ownership language. “The app is yours” is niet genoeg. Je hebt duidelijkheid nodig over source code, repositories, build scripts, documentatie, design files, third-party components en deployment access.
Het doel is niet om je voor te bereiden op een slechte relatie. Het doel is om zeker te weten dat het project normale zakelijke veranderingen kan overleven.
Category 3: Contract, pricing model, and scope changes
Deze categorie controleert hoe financieel risico wordt afgehandeld. Veel app projecten falen niet omdat de eerste estimate fout was. Ze falen omdat het contract niet definieerde hoe verandering zou worden afgehandeld.
| Question | Why it matters | Red flag answer | Good answer |
|---|---|---|---|
| “Is this a fixed-scope or time-and-materials contract, and what triggers a change order?” | Fixed-scope en T&M-contracten dragen verschillende risico’s. | “It is mostly fixed, but we can adjust.” Geen duidelijke trigger voor change orders. | Noemt het model. Definieert wat telt als een nieuwe feature, gewijzigde requirement, third-party delay of out-of-scope request. |
| “If we add a feature during the project, what is the process and typical cost impact?” | Scope changes zijn normaal. Het proces mag niet geïmproviseerd worden. | “We can usually fit in small changes.” Geen schriftelijke impact assessment. | Schriftelijke change request, impact estimate, approval step en timeline update vóór implementation. |
| “What are the payment terms, and what happens if a milestone is delayed on your side?” | Payment terms moeten aansluiten op delivery progress. | Monthly billing loopt door zelfs wanneer vendor-caused delays delivery blokkeren. | Milestones zijn gekoppeld aan accepted deliverables. Vendor-caused delay heeft een duidelijke remedy of payment adjustment. |
| “Are there costs not included in this proposal, such as maintenance, hosting, App Store fees, third-party APIs, or support?” | Hidden costs veranderen het echte budget na ondertekening. | “Those are standard costs you handle separately.” Geen estimate van uitgesloten items. | Zet exclusions duidelijk op een rij en geeft geschatte jaarlijkse running costs. |
Vraag 12 is de vraag die veel teams missen. De build price is niet de volledige kost. Hosting, maintenance, support, analytics tools, third-party APIs, App Store accounts, security testing en post-launch changes kunnen het Year 1-budget verhogen. Gebruik [hidden costs of mobile app development] om te controleren welke kostencategorieën vóór ondertekening moeten worden verduidelijkt.
Als je bijna tekent met een app development agency, gebruik het laatste gesprek dan om de punten te verduidelijken die delivery risk beïnvloeden: team structure, scope changes, pricing model, DPA, SCCs, governing law, access control, escalation path en post-handover ownership. Sunbytes kan je helpen deze vragen te reviewen voordat je je commit. Talk to Sunbytes before signing.
Category 4: GDPR, data processing, and security
Deze categorie is waar Nederlandse en Europese procurement vaak meer precisie nodig heeft. Als de app persoonsgegevens verwerkt, is de agency relationship niet alleen een delivery relationship. Het kan ook een data-processing relationship zijn.
| 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 vereist dat verwerking door een processor wordt geregeld door een contract of andere juridische handeling. | “We will sort that out during the project.” Geen DPA klaar voordat personal data wordt verwerkt. | Heeft een DPA-proces klaar vóór projectstart. Bevat SCCs waar non-EU/EEA transfer van toepassing is. |
| “Where is project data stored: EU-only, or mixed with non-EU storage?” | Data location beïnvloedt privacy, procurement en risk review. | Kan hosting regions niet noemen of gebruikt mixed regions zonder uitleg. | Noemt cloud provider en region. Kan EU-only storage ondersteunen wanneer het project dit vereist. |
| “Who has access to production data during development, and how is access controlled?” | Developers mogen niet standaard brede toegang hebben. | “The whole team has access.” Geen access policy of review process. | Gebruikt role-based access, least-privilege access, named approvers en documented reviews. |
| “What is your incident response procedure if a data breach occurs during development, and when do you notify us?” | De klant heeft genoeg tijd nodig om te beoordelen en de toezichthouder te informeren waar vereist. | “We would contact you if something happens.” Geen timeline, geen incident response process. | Heeft een written incident response process en committeert zich aan snelle client notification na discovery. |
Voor Q13 is de DPA geen voorkeur. Article 28 GDPR stelt dat verwerking door een processor moet worden geregeld door een contract of andere juridische handeling waarin processing scope, duration, purpose, data types, data-subject categories en obligations worden vastgelegd.
Als personal data vanuit de EU/EEA naar een land buiten de EU/EEA gaat, vraag dan of Standard Contractual Clauses van toepassing zijn. De Europese Commissie heeft in 2021 gemoderniseerde SCCs uitgegeven voor doorgiften van EU/EEA controllers of processors naar non-EU/EEA recipients die niet onder de GDPR vallen.
Voor Q16 vereist Article 33 GDPR notification aan de supervisory authority without undue delay en, waar haalbaar, binnen 72 uur nadat men zich bewust is geworden van een personal data breach, tenzij het onwaarschijnlijk is dat de breach een risico oplevert voor de rechten en vrijheden van personen.
Als je app personal data zal verwerken, gebruik dan GDPR compliance requirements for mobile apps om de vereisten te begrijpen voordat je het contract tekent.
ISO 27001-certificering is ook een nuttig signaal, maar geen vervanging voor specifieke antwoorden. Vraag bijvoorbeeld hoe access control werkt binnen het project. ISO 27001:2022 Annex A bevat access-control expectations zoals role-based en least-privilege access. Voor de bredere certificeringsvraag kun je [what ISO 27001 certification means for your app project] gebruiken.
Category 5: References, track record, and conflict resolution
Deze categorie test hoe de agency zich gedraagt wanneer het project niet langer in sales mode zit. Goede referenties en duidelijke escalation paths laten zien hoe de agency onder druk handelt.
| 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?” | Een relevante referentie controleert of de agency recent vergelijkbaar werk heeft geleverd. | Biedt alleen schriftelijke testimonials. Referentie is oud, niet relevant of buiten je marktcontext. | Biedt één of twee relevante referenties, afhankelijk van client permission en NDA-limits. |
| “If the project is behind schedule by Sprint 4, who owns the delay and what is the remediation process?” | Dit test accountability voordat de relatie onder druk staat. | “Delays are usually caused by changing requirements.” Geeft de klant de schuld voordat het werk start. | Scheidt client-caused en vendor-caused delays. Benoemt remediation steps en decision owners. |
| “If we disagree with your technical recommendation, how do we resolve it?” | Het antwoord laat zien of de agency zich opstelt als partner of alleen als code supplier. | “We do what the client asks.” Geen challenge process. Geen risk documentation. | Legt de recommendation uit, documenteert de trade-off en implementeert de final decision met duidelijke risk notes. |
| “Which law governs this contract, and which court has jurisdiction for disputes?” | Governing law beïnvloedt enforcement als de relatie stukloopt. | Non-Dutch governing law by default, geen jurisdiction clause of dispute forum buiten de verwachte procurement context. | Voor Nederlandse klanten kan de agency Dutch-law contracting en Dutch court jurisdiction bespreken waar toepasselijk. |
Vraag 19 is bijzonder nuttig. Je wilt geen agency die je input negeert. Je wilt ook geen agency die stilletjes een technical decision implementeert waarvan zij denken dat die risico creëert.
Een volwassen antwoord klinkt zo: “We documenteren ons advies, leggen de gevolgen van het alternatief uit en laten jou de uiteindelijke business decision nemen. Als je voor de optie met hoger risico kiest, leggen we die beslissing vast.”
Dat antwoord beschermt beide kanten.
De 5 vragen die Nederlandse bedrijven het vaakst vergeten te stellen
De meeste teams denken eraan om te vragen naar kosten, timeline en case studies. De vragen die ze overslaan, zijn meestal de vragen die te juridisch, te operationeel of te gedetailleerd voelen voor een salesproces.
De vijf vragen die het vaakst worden gemist zijn:
| Question | Why it gets missed | Why it matters |
|---|---|---|
| Q5. Who owns the code? | De proposal zegt “custom app,” dus de klant neemt aan dat ownership duidelijk is. | Source code, repositories, libraries en handover rights moeten expliciet zijn. |
| Q13. Is a DPA ready? | Data-processing terms voelen als juridisch papierwerk. | Voor personal data processing moet de DPA worden geregeld voordat het werk start. |
| Q17. Can we speak to a similar Dutch or EU client? | Vragen om een referentie kan ongemakkelijk voelen. | Een relevante referentie test delivery reality, niet sales quality. |
| Q20. Which law governs the contract? | Legal clauses lijken boilerplate. | Governing law beïnvloedt enforcement, dispute handling en procurement comfort. |
| Q4. Is the team dedicated or shared? | “Dedicated team” klinkt vanzelfsprekend. | De definitie van de agency komt mogelijk niet overeen met die van jou, tenzij deze schriftelijk is vastgelegd. |
Deze vragen zijn geen teken van wantrouwen. Ze zijn normale procurement hygiene voor een project dat tienduizenden of honderdduizenden euro’s kan kosten.
Hoe Sunbytes pre-contractvragen beantwoordt
Een professionele app development partner moet due diligence behandelen als onderdeel van delivery discipline. Het pre-contractgesprek is waar beide partijen delivery expectations verduidelijken voordat de eerste sprint start.
Voor Nederlandse en Europese klanten verduidelijkt Sunbytes de praktische vragen vóór ondertekening: wie aan het project werkt, hoe het deliverymodel is gestructureerd, hoe scope changes worden afgehandeld, welke data-processing terms gelden, hoe security responsibilities worden toegewezen en wat er gebeurt als het project escalatie nodig heeft. Via Digital Transformation Solutions ondersteunt Sunbytes mobile app development met delivery planning, engineering, QA/testing, maintenance en support. Het doel is om het laatste pre-contractgesprek specifiek genoeg te maken zodat delivery met minder aannames start.
Why Sunbytes
Sunbytes is een Nederlands technologiebedrijf met het hoofdkantoor in Nederland en een delivery hub in Vietnam. Met 15+ jaar actief in Vietnam, 300+ engagements geleverd in 20+ landen, ISO 27001-certificering en deliveryteams die binnen 2–4 weken kunnen worden opgezet, helpt Sunbytes Nederlandse en Europese bedrijven de contract-, team-, security- en deliveryvragen te verduidelijken voordat development start.
- Digital Transformation Solutions: We bouwen en moderniseren digitale producten met senior engineeringteams binnen custom development, QA/testing, maintenance en support. Voor mobile app projecten betekent dit dat scope, architecture, team model en delivery plan worden verduidelijkt voordat execution begint.
- CyberSecurity Solutions: We verminderen delivery risk via praktische security services en compliance readiness. Voor app development ondersteunt dit de vragen die Nederlandse klanten vóór ondertekening beantwoord moeten krijgen: data processing, access control, incident response, DPA/SCCs en secure-by-design responsibilities.
- Accelerate Workforce Solutions: We helpen bedrijven delivery capacity op te schalen wanneer groei meer mensen vereist dan het interne team alleen kan leveren. Voor mobile app projecten kan dit dedicated team setup, recruitment en workforce planning ondersteunen wanneer langetermijn delivery capacity belangrijk is.
Breng je proposal, contractvragen, delivery concerns en security requirements samen in één gefocust gesprek. Plan een consult met ons om team structure, scope-change risk, GDPR requirements, access control, escalation paths en delivery ownership te verduidelijken voordat je je commit aan een app development agency.
FAQs
De belangrijkste vraag is: “Who owns the code, repositories, documentation, and handover rights?” Als het contract onduidelijk is, kun je later moeite krijgen om de app te onderhouden of naar een andere partner te verplaatsen. Ownership moet in het contract staan, niet worden aangenomen op basis van de proposal.
Ja, als de agency namens jou personal data zal verwerken. Article 28 GDPR vereist dat processor relationships worden geregeld door een contract of andere juridische handeling. Voor Nederlandse bedrijven moet dit worden afgehandeld voordat personal data het developmentproces binnenkomt.
Ja. Een professionele agency moet reference checks verwachten voordat een serieus contract wordt getekend. De beste referentie komt van een Nederlandse of Europese klant met een vergelijkbaar projecttype, scope of deliverymodel.
Vraag of ze kunnen werken met de DPA van je legal team of een erkende Nederlandse verwerkersovereenkomst-template. De Autoriteit Persoonsgegevens legt uit dat verwerkersovereenkomsten de afspraken tussen verwerkingsverantwoordelijke en verwerker vastleggen, en dat deze overeenkomsten moeten voldoen aan AVG/GDPR-vereisten. Nederlandse juridische aanbieders zoals ICTRecht publiceren ook guidance over standaard verwerkersovereenkomsten in de praktijk.
Een goede agency moet alle 20 vragen kunnen beantwoorden, zelfs als sommige antwoorden na de call nog legal of delivery-team confirmation nodig hebben. De red flag is niet “we will confirm this in writing.” De red flag is de vraag ontwijken, een salesantwoord geven of normale due diligence als een probleem behandelen.
Stel deze vragen voordat het contract definitief wordt gemaakt. De antwoorden moeten het contract vormen, niet ernaast bestaan. Als een antwoord belangrijk is voor delivery risk, ownership, data processing, payment of escalation, moet het worden opgenomen in de agreement of statement of work.
Laten we beginnen met Sunbytes
Laat ons uw eisen voor het team weten en wij nemen meteen contact met u op.
