A form for holiday requests, an approval for purchase orders, a list that fills itself from the mailbox: things like these can now be built without a programmer. Tools such as Microsoft Power Apps and Power Automate, Zapier, Make, Airtable or Ninox promise exactly that - assemble an application by clicking instead of writing it. The word for it is low-code: little program code, a lot of user interface.

The question comes up in almost every first conversation: “Couldn’t we just do this ourselves in Power Apps?” Often the answer is yes. Sometimes it is: yes, but not for long. This article helps you tell the two answers apart.

What low-code means

Low-code tools provide ready-made building blocks: forms, tables, approval steps, connections to services such as Microsoft 365, SharePoint, Shopify or a mailbox. You arrange the blocks in a visual editor and define what happens when. Broadly, there are two kinds:

  • Application builders such as Power Apps, Airtable or Ninox. They produce screens with tables and forms in which staff enter and view data.
  • Workflow tools such as Power Automate, Zapier or Make. They connect services with each other: when an email with an attachment arrives, file it in SharePoint and add a row to the list.

What the toolkits are good for

Examples from everyday business that run well in a toolkit:

  • Field staff record visit reports in a form on their phone instead of typing them into an email in the evening.
  • Purchase orders above a certain amount go through an approval: request, review by management, reply to the requester.
  • A list of open complaints that several colleagues maintain at the same time, without emailing spreadsheets back and forth.
  • New orders from the online shop land in the accounting program automatically, without anyone retyping them.

What these examples have in common: few users, a clear workflow, data that so far lived in a spreadsheet or nowhere at all, and services that already run in the cloud. For the spreadsheet that has grown too big, a toolkit is often the right next step.

Where the toolkits stop

The limit rarely shows at the start. It shows when the application is a success and grows.

Many users

What works well for a handful of colleagues becomes sluggish with the whole workforce. Lists get long, views get slow, and every change touches everyone at once. Then there is the licensing model: many vendors charge per user. Connect the whole company and you pay for every single person.

Permissions that depend on customer and department

Who may see what? Sales sees the selling prices but not the purchasing terms; the northern site sees its own orders, not the southern site’s; the fitter sees only his own jobs. Toolkits do have permissions, but usually coarse ones: edit or read, table yes or no. As soon as permissions depend on customer, department and status at the same time, it becomes a bodge - or copies of the application appear, one per department.

Connecting to your own ERP

Ready-made connections exist for cloud services. For your in-house ERP, the inventory system or the old Access database, they usually do not. Then you need an intermediate step that fetches data and writes it back - and that is often more programming than the rest of the application. Whether a connection is possible depends on the system; it can be built where possible, but not promised in advance.

Dependence on the vendor

The application runs only in this toolkit. If the vendor changes features or licensing, your options and costs change with them. A Power App cannot be moved.

Maintenance by one person

Usually a colleague who knows the workflow well built the application. He is then the only one who understands it. If he changes department or company, the application is left without a keeper. That is no reproach to the colleague: the business left him the task because nobody else was there.

Toolkit or built with AI?

Alongside the toolkits there is now a second route: tools such as Lovable or Cursor write real program code on instruction. The result looks like custom software and, in form, it is. The difference from a toolkit: the code is yours and runs anywhere, but the frame the toolkit provides is missing - sign-in, permissions, backups, operation. What is typically missing is covered in Built it yourself with AI. Both routes have their place; neither replaces the other.

How to tell you have outgrown the toolkit

  • The application has more exceptions than rules, and every new requirement takes longer than the last.
  • Permissions are solved with separate copies of the application.
  • Data from the ERP is copied into the toolkit by hand - or back out.
  • The workflow hangs on one colleague, and nobody else dares touch the application.
  • The licence bill grows with every user although the application stays the same.
  • The small helper has become a department’s main working tool - and was never meant to be.

How to proceed

  1. Start with the toolkit when the workflow is small and the users are few.
  2. Write down what the application does, where its data lives and who maintains it - one page is enough.
  3. Go through the list above regularly, ideally together with the colleague who built the application.
  4. Once the limit is reached, use the toolkit as your template. It shows exactly which fields, steps and approvals the workflow needs - the best starting point for custom software that provides for permissions, connections and many users from the start.

For us this transition is the usual route: sign-in, permissions, workspaces and collaboration come with ElbDesk, the foundation we build on - only your workflow is built. If you have an ERP, it stays - accounts and warehouse stay out of it.