Most low-code evaluations measure the first week: how quickly a form appears, how easy the first screen is to build. That matters for a quick internal tool. For a system your organization depends on, like a licensing program, a case management system, or a citizen portal, the first week is the easy part. What matters is year three: the integrations, the security reviews, the change requests, and the team that has to keep it all running.
Here are the questions worth asking before you choose.
1. Start from the system, not the tool
Pick a real problem before you look at platforms: one critical process, with its real data, its real users, and the systems it has to talk to. Then evaluate every platform against that problem, not against its own demo.
Be clear about what you’re building. A team tracker and a system that issues licenses to the public need very different things from a platform, and a platform that’s perfect for one can be the wrong choice for the other.
2. Who builds it, and who owns it?
Some platforms are built for business users and hit a ceiling when the requirements get serious. Others need a full development team for every change. For an important system, look for a platform where a small team (people who understand the process, working with developers) can own the whole thing: the data, the processes, the portals, and the integrations.
Ask the vendor: how many people does it take to run a system like ours, and to keep changing it?
3. What happens when you reach the platform’s limits?
Every platform eventually meets a requirement it wasn’t designed for. What matters is what happens next. If the answer is a workaround, the workarounds pile up, and the new system slowly becomes the next legacy system.
Ask how the platform is extended: inline code where it’s needed, your own components that appear in the builder like the built-in ones, and calls out to your own services. A platform with no dead ends is one you won’t have to replace.
4. How does it connect to what you already have?
No important system runs alone. It reads from your ERP, writes to your CRM, and exchanges data with legacy systems and outside agencies. Check that the platform connects through REST and SOAP APIs, reads external databases, and lets you publish secure APIs of your own, and that a connection set up once can be reused everywhere.
5. How do people sign in?
Staff expect to use the identity they already have. Check for single sign-on with your identity provider (Entra ID, Okta, Google, and others through OpenID Connect, or Active Directory) and for roles that follow group membership, so access is managed in one place.
6. Where does it run?
Some systems can run in the vendor’s cloud. Others have to stay in your own cloud, or in your own data center, sometimes fully disconnected from the internet. Ask whether the same platform runs in all of those places, and who operates it in each.
7. What evidence comes with the security claims?
Ask for certifications, not adjectives: SOC 2 Type II and ISO 27001, recent penetration test reports, and help with your security questionnaires. Then check the details: secrets encrypted and masked, HTTPS enforced, sign-ins, API calls, and configuration changes logged.
8. How are changes controlled?
An important system changes for years. Every change needs to be recorded (who made it, when, and what), with versions kept in your own Git repository and earlier versions restorable when something goes wrong.
9. What happens if the vendor goes away?
Business continuity is part of the evaluation, not an afterthought. Ask who owns the configurations, integrations, and custom code built for you, whether source code escrow is available, and whether a perpetual license keeps your applications running without renewal.
Look at how the platform is licensed, too. Pricing per end user punishes success: the more residents or customers use the system, the more it costs. Licensing that isn’t tied to end users lets a system grow with its audience.
10. Test it on your problem
A demo shows what the vendor chose to show. Ask to see the platform applied to the critical problem you started with (your data, your process, your integrations) and ask the people who’ll own the system to judge it.
Start with one critical problem. Choose the platform that lets you expand wherever it creates value.