Checklist platformselectie: vragen die je stelt vóór je tekent

Een checklist met aangevinkte vakjes, drie platformopties links en een vergrootglas rechts.
  • Aanpak & platformselectie
  • No-code- & low-code-ontwikkeling

Download de checklist (pdf)

Een low-code- of no-codeplatform kiezen is makkelijk om mee te beginnen en lastig om terug te draaien. De demo’s zien er geweldig uit, het salesteam is vriendelijk, en de eerste app draait binnen een week. De vragen die er echt toe doen, komen meestal een jaar later: als de licentierekening groeit, als je tegen een grens aanloopt, of als je van het platform afscheid wil nemen.

Met deze checklist stel je die vragen voordat je tekent. Hij is leveranciersonafhankelijk en werkt voor elk platform, ook voor een vergelijking tussen een platform en AI-assisted development.

Zo gebruik je hem:

  • Beantwoord de vragen in deel 1 zelf, voordat je met een leverancier praat.
  • Gebruik deel 2 tot en met 6 in gesprekken met leveranciers, en vraag om bewijs, niet om beloftes.
  • Gebruik deel 7 om de demo’s en een eventuele proof of concept te plannen.
  • Niet elke vraag is voor jou even belangrijk. Markeer de vragen die dat wel zijn, en beoordeel platforms daarop.

Tip: download deze checklist als pdf, of print deze pagina. Hij is gemaakt om op papier te werken.

1. Fit: wat heb je eigenlijk nodig?

Beantwoord deze vragen zelf, vóór de eerste demo.

  • Wat voor applicaties ga je bouwen: proofs of concept, formulieren en workflows, interne tools, apps voor klanten, of bedrijfskritische systemen?
  • Wie gaat ze bouwen: professionele developers, zakelijke gebruikers, of allebei?
  • Wie onderhoudt ze over twee jaar?
  • Is een platform überhaupt de juiste aanpak, of past AI-assisted development of traditionele code beter? (Soms is het antwoord “helemaal geen platform”.)
  • Welke drie tot vijf applicaties zou je als eerste bouwen?

2. Functionaliteit en grenzen

  • Kan het koppelen met je bestaande systemen (je identity provider, ERP, CRM, databases), en via standaardmethoden zoals REST API’s?
  • Hoe complex kan het datamodel worden voordat het pijn gaat doen?
  • Kun je eigen code toevoegen waar het platform tegen zijn grenzen aanloopt? In welke taal, en hoe?
  • Ondersteunt het wat je gebruikers nodig hebben: mobiel, offline gebruik, toegankelijkheid, meerdere talen?
  • Welke AI-functies biedt het: bouwen met AI, AI in de apps zelf, AI-agents bouwen? Welke modellen zitten daarachter?

3. Governance en security

  • Ondersteunt het single sign-on met je identity provider, en toegang op basis van rollen?
  • Waar worden je gegevens opgeslagen en verwerkt? Kun je kiezen voor de EU?
  • Welke certificeringen heeft de leverancier (bijvoorbeeld ISO 27001 of SOC 2), en kun je de rapporten inzien?
  • Zijn er auditlogs: wie heeft wat gewijzigd, en wanneer?
  • Hoe zijn back-ups geregeld, en hoe snel kun je herstellen?
  • Kan IT alles zien en beheren wat citizen developers bouwen?
  • Voor AI-functies: worden je gegevens gebruikt om modellen van de leverancier of een derde partij te trainen?

4. Kosten

  • Wat is het licentiemodel: per gebruiker, per app, per omgeving, of op basis van gebruik?
  • Wat kost het in jaar één, en in jaar drie als het gebruik verdrievoudigt? Vraag naar allebei.
  • Welke kosten komen erbij: extra omgevingen, premium connectors, AI-credits, supportniveaus?
  • Wat kost training, en hoe lang duurt het voordat je team productief is?
  • Hoe makkelijk kun je afschalen als je minder nodig hebt?

5. Lock-in en vertrek

De belangrijkste vragen, en de vragen die het minst worden gesteld.

  • Als je vertrekt, wat kun je dan meenemen: je data, je applicatielogica, je code?
  • In welk formaat, en kan iets anders het draaien?
  • Welke opzegtermijn geldt er, en wat gebeurt er met je data na je vertrek?
  • Welke delen van je applicaties werken alleen op dit platform?
  • Wat zou het realistisch kosten om je drie belangrijkste apps ergens anders opnieuw te bouwen?

6. De leverancier en zijn ecosysteem

  • Hoe lang bestaat de leverancier al, en hoe wordt hij gefinancierd? Is er een kans dat hij wordt overgenomen of stopt?
  • Hoe ziet de roadmap eruit voor de komende twee jaar, vooral voor AI?
  • Kun je in jouw regio developers en partners voor dit platform vinden?
  • Is er een actieve gebruikerscommunity, en goede documentatie?
  • Kun je met twee of drie vergelijkbare referentieklanten praten, zonder dat de leverancier erbij zit?

7. De demo en de proof of concept

  • Geef elke leverancier hetzelfde scenario: een echte workflow of een echt proces uit je eigen organisatie. Niet hun favoriete showcase.
  • Laat de leverancier een deel ervan live bouwen of aanpassen, zodat je ziet hoe het werkt, niet alleen hoe het eruitziet.
  • Beoordeel elke demo op de vragen die je als belangrijk hebt gemarkeerd.
  • Overweeg voor de beste één of twee kandidaten een korte proof of concept: één realistische use case, gebouwd door je eigen mensen met hulp van de leverancier.
  • Leg vast waarom je hebt gekozen, niet alleen wat. Je toekomstige zelf wil dat weten.

Goed kiezen kost tijd, en bespaart veel meer

Een goede platformkeuze kost een paar weken. Een slechte kost jaren. Deze checklist neemt de beslissing niet voor je, maar zorgt ervoor dat je met open ogen kiest.

Doe je dit liever niet alleen? Ik begeleid onafhankelijke platformselecties: van eisen tot een goed onderbouwd advies, zonder commerciële banden met welke leverancier dan ook.

Een platform kiezen? Laten we het onafhankelijk doen.

Diensten vooral in de Benelux, op locatie of op afstand. Internationale projecten op aanvraag.