No-code platforms are no longer a side experiment. In 2026, operations teams use them for listings, case tracking, memberships, inventories, and the internal tools that never quite justified a custom software project. The category is also crowded, and the demos look similar. Every vendor can show a form, a table, and a chart in the first fifteen minutes.
This checklist is for the people who have to live with the choice: the operations lead who owns the process and the technical lead who will be asked to connect it to a website, an accounts tool, or a partner system. Use it to compare platforms, including AppClust, on the points that still matter after the trial expires.
Start from the record, not the template gallery
Template galleries are a sales aid. Your work is a set of records with rules. Before you book a second demo, write down three record types you need in the first release and the relationships between them. A customer has many jobs. A listing has one owner and many documents. A membership has a status and a renewal date.
Ask the vendor to model those three records in the demo, using your names for the fields. A platform that can only shine with its own sample CRM is a platform you will be bending your process to fit. A platform designed for custom modules should let you define fields, field types, and relationships without a change request for each one.
Also ask what happens when a field needs to change after go-live. Adding a status, renaming a column, or relating two modules later is normal. If every change requires a services project, the tool is not no-code for the team that will maintain it.
Permissions are part of the product
Internal apps fail in quiet ways when everyone can edit everything, or when the only privacy model is 'share a link'. List the roles you actually have. A typical first app needs an admin, people who create and edit records in their area, and people who can view but not change.
Check that permissions can follow the record, not only the screen. A regional manager should see their region's rows. A finance reviewer should see amounts without editing operational notes, or the reverse. Ask how you remove a leaver's access the same day they leave, and whether API keys are separate from user logins.
If the app will hold customer lists, staff data, or commercial terms, ask where the data is stored and how you export it. You should be able to leave with your records. A checklist that skips export is a checklist that skips the exit.
The API is the difference between an app and a silo
An internal tool that cannot talk to anything else becomes the next spreadsheet. You will copy rows out of it for the website, the invoice run, or the partner portal. Ask for the API on the same day as the form builder.
You want authenticated read and write for the modules you create, not a fixed list of objects the vendor imagined. You want a way to know which fields are safe to expose to a public site. You want a straight answer on rate limits, keys, and what an integration breaks when you add a field.
AppClust's model is an API on the custom modules you define, so a site or another system can use the same records. Read the feature list with that test in mind, and ask to see a request against a module created during the demo, not against a sample dataset.
Webhooks or an equivalent event matter if another system must react when a status changes. If the vendor says you can poll, ask how often you are allowed to poll and what you are supposed to do when a record changes between polls. Polling is acceptable for a nightly report. It is a poor fit for a customer waiting on a status.
Maintenance after the implementer leaves
The expensive part of internal software is the second year. Ask who changes a form, a permission, or a relationship when the original builder is gone. If the answer is only the vendor's professional services team, price that into the comparison. If a trained admin on your side can do it, ask to watch them do it in the trial, not in a video.
Look at audit history. You will need to know who changed a price, a status, or a customer record. A platform without a change history forces you back to side channels the first time two people disagree.
Look at backups and restore in plain language. What is retained, for how long, and who can request a restore? You are not looking for a security whitepaper in this conversation. You are looking for a sentence your operations lead understands.
Fit the commercial model to a first workflow
Price the first workflow, then the next two, not an unlimited-enterprise story. Ask what is included: environments, users, modules, API calls, support, and the cost of a change after launch. Ask what happens if you pause for a quarter. Tools that are cheap until you connect the API are not cheap for this job.
Ignore headline user counts until you know whether a 'user' is someone who logs in, someone who is stored as a contact, or someone who hits the API. Those three numbers are not interchangeable, and proposals sometimes add them together.
Prefer a pilot with a cutover date over a proof of concept that never holds live data. A pilot has real rows, real roles, and a decision at the end to keep going or stop. A sandbox full of fake names will not tell you whether staff will abandon their sheet.
Questions worth sending before the proposal
Send these in writing so the answers are comparable.
Can we create our own modules and relationships, and can our admin change them after launch? Can we restrict rows and fields by role? Can an external site read and write the same records through an authenticated API? Can we export everything we stored? Where is the data hosted, and what does a restore look like? What do we pay for the first workflow, and what changes when we add a second? Who do we call when a field needs to change, and is that included?
A vendor who answers those directly is easier to evaluate than a vendor with a longer feature matrix. AppClust is aimed at this brief: custom modules, role-based access, and an API for the website or tools around them. Use the same questions on us that you use on anyone else. See how the platform is structured or talk to the team with your three record types written down. The right platform is the one that can hold those records after the demo team has left.
A scoring sheet that survives the sales call
Give each platform a score from one to five on six lines only: your records can be modeled without renaming the business, an admin can change a field after launch, roles can hide rows and fields, the API reads and writes those same modules, you can export the data, and the first-workflow price is written down. Anything the demo spent time on that is not on this list goes in a parking lot, not in the decision.
Do the scoring in the room, with the operations lead and the technical lead both present. If they disagree by more than a point on a line, you do not have an answer yet. Book another session and ask to see that line done live. A second demo that repeats the slide is not new evidence.
Weight the API and the admin-can-change-a-field lines above the polish of the first screen. You will look at the first screen for a week. You will live with field changes and integrations for years. A plain screen on a data model you control beats a polished screen you cannot extend.
What to do with the loser
Write down why you did not choose the other platforms, in the same six lines. Future you, or the next person in the role, will be pitched again in 2027. A one-page note stops the company from rerunning the whole evaluation because nobody remembers the objection. Keep the export sample and the API example from the winner in the same folder as that note.
Then run the pilot on live rows, with the cutover date on a calendar the team already uses. The evaluation is finished when someone creates a real record that used to go into the old sheet, not when the proposal is signed.
