Low-Code for Business Teams: Building Solutions Without Waiting on IT

A marketing team asks IT for an internal form linking campaign requests to the production calendar. The answer is that it joins the queue. Four months later the form does not exist, and the team has already solved the problem its own way: a shared spreadsheet, three status columns and a manual Friday reminder.

That gap — between the request nobody can service and the workaround nobody owns — is where low-code for business teams earns its place. Not as a way of doing without IT, but as a way of no longer blocking IT with requests it will never prioritise.

Low-code does not mean "no developers", it means "less code"

The difference between low-code and no-code is the ceiling, not the difficulty. A no-code tool hands you ready-made blocks and stops exactly where those blocks stop. A low-code tool hands you the same blocks and lets you write code at the points where they run out.

That shows up as very concrete details. n8n has a code node where you write JavaScript or Python midway through a workflow. Power Platform has Power Fx expressions inside fields that look like they only accept clicks. That escape hatch decides whether your solution survives the second change request or dies in it.

If you are still choosing the family of tool, the comparison between no-code and low-code covers the limits and exit costs of each. This article assumes that choice is made and deals with what comes next: who builds, with how much autonomy, and up to what point.

The IT queue is not slow for lack of willingness

The problem is rarely the priority IT assigns to your request. It is the arithmetic of who is available.

In 2023, 57.5% of EU enterprises that recruited or tried to recruit ICT specialists had difficulty filling those vacancies, according to Eurostat data on hard-to-fill ICT vacancies. The most frequently reported difficulty was not salary expectations: it was a lack of applications, cited by 43.24% of those enterprises.

In an SME that means one or two IT people who spend the day keeping what already exists alive. The campaign form request is not late because it is unimportant. It is late because it sits behind the mail server, the ERP migration and a backup problem.

In December 2022 Gartner predicted that by 2026 at least 80% of low-code tool users would sit outside formal IT departments, up from 60% in 2021. It is now 2026, and the forecast matters less than the cause: this is not enthusiasm for technology, it is a lack of alternatives.

What business teams genuinely build well in low-code

A small-scale example, because small scale is where this pays off most.

A five-person sales team receives roughly 70 quote requests a month by email. For each one: open the message, copy the details into a spreadsheet, create the folder on the drive, reply from a template and set a seven-day follow-up. Timed properly, that is about 14 minutes.

That is 980 minutes a month, a little over 16 hours. At a fully loaded cost of 25 EUR per hour — a stated assumption, not an official figure; the method for working out your own number is in the article on how much manual processes actually cost — that is around 400 EUR a month spent copying fields.

The low-code version is modest: a form replaces the email, the form writes to the spreadsheet or the CRM, the reply comes from a template and the follow-up is scheduled automatically. Built by someone on the sales team who is good with spreadsheets, in two or three days of work spread over a fortnight. IT was involved once, for half an hour, to approve the CRM connection.

The pattern repeats. The processes worth a business team's time are the ones it knows in detail and IT never will: the exceptions, who approves what, the client who insists on a PDF with a different header. Writing that specification down for someone else to build takes longer than building it.

Where low-code hits a wall

Four real limits, and they almost always appear in this order.

Licensing scales per person, not per use. The official Power Apps pricing page currently lists the Premium plan at USD 22 per user per month paid yearly, dropping to USD 14 above 2,000 seats. The detail that catches teams out is different: the public table now only shows per-user plans. A solution for six people is cheap; the same solution rolled out to 120 becomes a budget decision, not a team decision.

Some data lives on the inside. An ERP on your own server, a database with no API, a file that only exists on the local network. There is no route around IT here — and there should not be.

Volume and failure change the problem. A workflow that runs 40 times a day tolerates someone redoing it by hand when it breaks. At 40,000, you need retries, duplicate handling and alerting. That is engineering.

Technical debt has a name. A study published in MIS Quarterly Executive in 2024, based on 30 interviews with citizen developers and low-code platform experts, states the risk plainly: handing development to non-developers brings substandard software quality, shadow IT and technical debt. Its more useful conclusion is that governing citizen development is not the same as governing conventional software — it needs its own mechanisms.

The agreement with IT that makes low-code work

Not depending on IT to build is not the same as building without IT. What separates the two is four rules that fit on one page.

• One environment per team, never the default one. That is where sharing limits, data policies and solution checking apply. Power Platform's managed environments documentation describes exactly these controls, and every serious platform has an equivalent.
• A named person owning each solution. The worst case is not a badly built workflow. It is a business-critical workflow running in the personal account of someone who has left the company.
• A short list of forbidden data. Health data, card data, payroll files. If the process touches those, it goes to IT, no debate.
• A 30-minute quarterly review. What exists, how often it ran, what nobody uses any more. Switching off what died is worth more than auditing what lives.

These rules do not slow the team down. They prevent the conversation two years later, when someone asks who approved this.

One month, one process

The fastest way to find out whether low-code works in your company is to do it once, small.

1. Week 1 — pick a process with a clear owner, known volume and no sensitive data. Time it properly, no mental estimates.
2. Week 2 — build the ugly version. No polished interface, no edge cases, just the main path.
3. Week 3 — run it in parallel with the old process. It is uncomfortable, and it is where the exceptions nobody mentioned show up.
4. Week 4 — decide: adopt, fix or throw away. Throwing it away after a month is a good outcome; dragging it out for six is not.

The critical point is week 3, and it is about adoption, not technology. The article on designing a workflow your team will actually use covers why technically correct solutions get abandoned after three months.

The question to take into your next meeting

It is not "can we use low-code?". That one is settled, and the answer is yes, within limits.

The harder question is this: which request has been sitting in the IT queue for more than three months, who on the team understands it better than any developer would, and what is stopping that person from building it this week — with a written limit on how far they can go alone?