Platform selection checklist: questions to ask before you sign

Choosing a low-code or no-code platform is easy to start and hard to undo. The demos look great, the sales team is friendly, and the first app is up and running in a week. The questions that really matter tend to come up a year later: when the licence bill grows, when you hit a limit, or when you want to leave.

This checklist helps you ask those questions before you sign. It’s vendor-neutral, and it works for any platform, including a comparison between a platform and AI-assisted development.

How to use it:

• Answer the questions in part 1 yourself, before talking to any vendor.
• Use parts 2 to 6 in conversations with vendors, and ask for evidence, not promises.
• Use part 7 to plan the demos and an optional proof of concept.
• Not every question matters equally for you. Mark the ones that do, and score platforms on those.

Tip: download this checklist as a PDF, or print this page. It’s designed to work on paper.

1. Fit: what do you actually need?

Answer these yourself, before the first demo.

• What kind of applications will you build: proofs of concept, forms and workflows, internal tools, customer-facing apps, or business-critical systems?
• Who will build them: professional developers, business users, or both?
• Who will maintain them in two years’ time?
• Is a platform the right approach at all, or would AI-assisted development or traditional code fit better? (Sometimes the answer is “no platform at all”.)
• Which three to five applications would you build first?

2. Functionality and limits

• Can it connect to your existing systems (your identity provider, ERP, CRM, databases), and through standard methods like REST APIs?
• How complex can the data model get before things become painful?
• Can you add your own code where the platform reaches its limits? In which language, and how?
• Does it support what your users need: mobile, offline use, accessibility, multiple languages?
• What AI features does it offer: AI-assisted building, AI in the apps themselves, building AI agents? Which models are behind them?

3. Governance and security

• Does it support single sign-on with your identity provider, and role-based access?
• Where is your data stored and processed? Can you choose the EU?
• Which certifications does the vendor have (for example ISO 27001 or SOC 2), and can you see the reports?
• Are there audit logs: who changed what, and when?
• How are backups arranged, and how quickly can you restore?
• Can IT see and manage everything citizen developers build?
• For AI features: is your data used to train the vendor’s or a third party’s models?

4. Cost

• What is the licence model: per user, per app, per environment, or based on usage?
• What does it cost in year one, and in year three if usage triples? Ask for both.
• Which costs come on top: extra environments, premium connectors, AI credits, support levels?
• What does training cost, and how long before your team is productive?
• How easy is it to scale down if you need less?

5. Lock-in and exit

The most important questions, and the ones asked least.

• If you leave, what can you take with you: your data, your application logic, your code?
• In which format, and can anything else run it?
• How much notice do you need to give, and what happens to your data after you leave?
• Which parts of your applications only work on this platform?
• What would it realistically take to rebuild your three most important apps elsewhere?

6. The vendor and its ecosystem

• How long has the vendor existed, and how is it financed? Is there a chance it gets acquired or stops?
• What does the roadmap look like for the next two years, especially for AI?
• Can you find developers and partners for this platform in your region?
• Is there an active user community, and good documentation?
• Can you talk to two or three reference customers similar to you, without the vendor in the room?

7. The demo and the proof of concept

• Give every vendor the same scenario: a real workflow or process from your own organization. Not their favorite showcase.
• Let the vendor build or adapt part of it live, so you see how it works, not just how it looks.
• Score each demo on the questions you marked as important.
• For the top one or two candidates, consider a short proof of concept: one realistic use case, built by your own people with the vendor’s help.
• Write down why you chose, not just what. Future you will want to know.

Choosing well takes time, and saves much more

A good platform choice takes a few weeks. A bad one costs years. This checklist won’t make the decision for you, but it makes sure you decide with your eyes open.

Would you rather not do this alone? I run independent platform selections: from requirements to a well-founded recommendation, with no commercial ties to any vendor.