When low-code makes sense (and when it doesn't)

01.Where low-code fits well

Low-code works best on software that supports your business but is not the business. Think of the tools your own staff and clients use to get work done.

• Internal tools: admin panels, back-office screens, data entry and review queues.
• Workflows and approvals: leave, purchase, onboarding, exceptions, anything with steps and sign-offs.
• Client portals: status, documents, requests and simple self-service.
• Prototypes: a working screen to test an idea in days, before committing a budget.
• Processes that change often: if the rules shift every quarter, a platform that lets you change them in hours is a gift.

A typical example is an approvals process that currently lives in email. The steps are clear, the users are known, the data already exists somewhere. A low-code build gives you roles, history and notifications quickly. A custom build would give you the same thing, later, at higher cost, with no real advantage to the user.

02.Where it does not fit

Low-code is a poor fit when the software itself is what you sell, or when you need to control every detail.

• Highly custom user experiences: if your design is the product, platform components will fight you.
• Very high scale: platforms have limits on records, concurrent users and API calls. Some are generous. Some are not.
• Complex algorithms: heavy calculation, optimisation or machine learning belong in code, even if a low-code front end calls them.
• Your core differentiator: do not build the thing that makes you different on a platform that your competitors can also rent.

A good rule: if a customer would choose you partly because of how this software works, write it in code.

03.Four checks before you commit

Before picking a platform, answer these four questions in writing.

• Who maintains it? Someone must own it after launch. If the answer is "the developer who built it", you have a key-person risk. If the answer is "nobody", you will have a stale tool in a year.
• What is the lock-in? Ask how you export your data, your logic and your user records. Ask what it would cost to move. You may still accept the lock-in, but know the price.
• What is the security model? Check single sign-on, role design, audit logs, data residency and how external connectors are controlled. Do not assume the defaults are right for you.
• What happens at 10x usage? Find the pricing tiers and technical limits. A tool that is cheap for 20 users can become expensive for 200. Work out the number now.

04.A simple example of the trade-off

Imagine two requests on the same week. The first is a leave-and-expenses approval tool for 150 staff. The second is a pricing engine that quotes customers in real time using proprietary rules. The first is a textbook low-code case. The second is closer to your core logic, needs testing, versioning and performance control, and should be written in code. Putting both on one platform because it is "our standard" is where teams get into trouble.

Hybrid designs are common and sensible. Use low-code for the screens and workflow, and call a small custom service for the hard calculation. You get speed where it helps and control where it matters.

05.A scoring approach that works

Opinions about platforms get heated. A simple scoring sheet cools things down. For each project, score these factors from one to five, then look at where the total lands.

• Uniqueness of the experience: how much does the interface need to be unlike anything standard?
• Expected scale: how many users, records and calls in year two?
• Rate of change: how often will the rules move?
• Strategic weight: would losing control of this hurt the business?
• Team capability: who can build and run it?

A high score on rate of change and a low score on uniqueness and strategic weight points to low-code. The reverse points to code. Mixed scores point to a hybrid. The point is not the number. The point is that the team has to say the reasons out loud, and a quiet disagreement becomes visible before money is spent.

06.The people side of low-code

Platforms promise that business users can build their own tools. Sometimes that is true. It is also how companies end up with forty unreviewed apps, three of which hold customer data. If you let more than one team build, set rules from the start.

• Keep separate environments for building, testing and live use.
• Give every app a named owner and a short description.
• Review any app that touches client data or money before it goes live.
• Use shared connectors and shared data definitions, not copies.
• Retire apps nobody uses.

Good governance costs a few hours a month. Its absence costs far more when an owner leaves and an app stops working.

07.What the first project teaches you

Your first low-code build is also a test of the platform's limits. Watch for a few signals. If simple changes take days because of workarounds, the platform is fighting you. If every request needs a licence upgrade, the pricing model does not suit your pattern of use. If your best developers avoid it, ask why. Treat the pilot as a cheap way of finding out, and write down what you learn.

08.Cost over time

Low-code often looks cheap at the start and different at scale. Licences usually grow with users, apps or usage. A build that costs little in month one can cost a lot in year three if every new user adds a seat. Work out three numbers before committing: the cost at today's usage, at double, and at ten times. Compare them with the cost of a custom build plus its upkeep. Sometimes low-code still wins. Sometimes the lines cross, and it is better to know that now.

09.Common mistakes

• Choosing the platform before understanding the process.
• Letting every department build its own apps with no naming, ownership or review.
• Ignoring licensing until the bill arrives.
• Treating a prototype as the finished product.
• Skipping the audit trail because "it is only internal".
• Building the same logic in five places instead of once.

10.What to do next

• List the three software requests you have pending.
• Mark each one as "supports the business" or "is the business".
• Run the four checks on the first group.
• Pick one small, visible project as a pilot, with a named owner.
• Write down your governance rules before the second app, not after the tenth.

If you are unsure which side of the line a project falls on, a short scoping conversation usually settles it. At Brandsmashers, we build on low-code platforms where they fit and in code where they do not, and we will tell you which is which, even when the answer is that you do not need us.