A managing director or head of technology is often asked a short question: "Can we build this in a low-code platform?" The honest answer is usually "probably, for now". The better question is whether low-code is enough for the next three years, and that can be answered before anyone builds anything.
This article is about the decision before you choose. If you already feel the platform getting in the way, see when low-code breaks and how to recognise the platform ceiling.
Why ask before, not after
The first app on a low-code platform is cheap and fast, which is exactly why it is a poor test. The cost shows up with the fifth app, the second integration and the first request that the platform does not support. By then the data, the users and the habits are on the platform, and switching means rebuilding. Six questions, answered in one meeting, move that discovery to the start.
The six questions
1. How many people will use it, and how often? Write down the number of named users today and in three years, and split them into people who edit and people who only view. Many platforms price per user, and the price of a casual viewer can equal the price of a daily editor. A tool for one team of ten is a different decision from a tool for the whole company.
2. How many exceptions does the process have? Take ten recent cases and mark how many followed the standard path without a manual workaround. Low-code works best when most cases are standard and the exceptions can be handled by a person. If every third case needs a special rule, you will spend the savings on configuring those rules.
3. What does it need to connect to? List every system the tool must read from or write to: accounting, e-mail, the customer database, a warehouse system. For each one check in the vendor's own documentation whether a ready connector exists, whether it reads, writes or both, and what limits apply to the number of calls. An integration that "can be done through an API" is a small development project, not a setting.
4. Who owns the data, and can you get it out? Ask where the data is stored, in which country, and how you export it. A usable export is complete, includes relationships between records and does not need the platform to be read. Test it with real data in the trial, not by reading the sales page. If the platform cannot export, the data is effectively rented.
5. What does growth cost? Calculate the price at today's volume and at three times that volume, using the vendor's published price list. Include users, records, automation runs and extra environments for testing. A platform that is cheap at ten users and expensive at fifty is not wrong, but you should know it before you choose.
6. How would you leave? Describe what leaving would take: how much of the logic can be reused, how long the rebuild would take and who in your company or at your supplier could do it. You do not need a detailed plan; you need an honest rough answer. For a structured version of this, see a low-code exit checklist covering limits, licence cost and migration in stages.
Reading the answers
Give each question a simple mark: favourable, unclear or unfavourable. Then use this table.
| Your answers | What it suggests |
|---|---|
| Mostly favourable, process simple and stable | Low-code is likely enough. Start with one process and review after six months. |
| Mixed, with one or two unclear | Run a short pilot that tests exactly the unclear points, such as the export or one integration. |
| Several unfavourable, especially exceptions and integrations | Look at a custom solution or a combination. The comparison in a build-versus-buy decision framework helps. |
| Unfavourable on data ownership or exit | Do not start until the vendor answers in writing. |
The marks are a conversation tool, not a scoring model. One unfavourable answer on data ownership can outweigh five favourable ones.
Two practical rules
- Start with a process that is allowed to fail. Choose something internal and non-critical for the first app. If the platform turns out to be wrong, the lesson is cheap.
- Name an owner for the platform itself. Low-code spreads quickly when anyone can build. Someone has to decide which apps are allowed, who maintains them and what happens when the builder leaves.
Common mistakes
- Judging by the demo. A demo shows the standard path. Ask the vendor to build your worst exception.
- Asking only the department that wants it. Finance, IT and whoever handles security should answer questions 3 and 4.
- Treating the licence as the whole cost. Time of the people who build and maintain apps is usually larger than the subscription.
- Deciding once and never reviewing. Put a review date in the calendar and repeat the six questions then.
Checklist
- Write down users now and in three years, split into editors and viewers
- Test ten recent cases for exceptions
- List all systems to connect and check each connector in the documentation
- Run a real data export in the trial
- Price the platform at three times today's volume
- Write a rough description of the exit
- Name an owner and set a review date
Sources
- Our related articles linked above.
- The questions are a general working practice, not a standard; adapt them to your organisation. Vendor features and prices change, so check each platform's current documentation and price list. No client results or market figures are claimed in this article.