- Low-code tools are a strong choice for internal screens over your own data, when someone in-house will own them.
- Costs usually grow with every person who uses the app, so price it at the headcount you expect in two years.
- Leaving is the hidden cost. Most platforms let you take your data, not a working app.
- Custom earns its keep when rules get complex, customers or partners log in, or the software is part of what you sell.
- A mix often works best: important rules in custom code, simple screens in low-code.
What low-code platforms are good at
Low-code platforms let you build working screens by dragging in tables, forms and buttons, then pointing them at your data. A little scripting fills the gaps. The good ones are fast, and they get better every year.
The market splits roughly three ways. Retool and Appsmith are internal-tool builders aimed at technical teams. They sit on top of the databases and business systems you already have. Microsoft Power Apps lives inside the Microsoft world and works naturally with SharePoint, Excel, Teams and Dataverse. OutSystems and Mendix sit at the enterprise end, with building, hosting and oversight in one platform.
Low-code is the right answer more often than custom software shops like to admit. Three situations stand out.
Simple data entry screens for one team. An approvals queue, an admin view over a database, a form that replaces an email chain. This is the sweet spot.
A team with someone to own it. A technical analyst, or an IT person who enjoys building, can keep a low-code app healthy for years.
Microsoft 365 organizations. If your files live in SharePoint and Excel and your people live in Teams, Power Apps is close at hand. Some Microsoft 365 licenses include limited Power Apps rights for apps that use Microsoft 365 data and standard connectors.
The real trade-offs
Licensing grows with people
Most low-code pricing is per person. Retool charges per user, with different rates for people who build apps, staff who use them and outside users. Self-hosting is only on its top tier.
In Power Apps, premium features such as Dataverse or premium connectors need a premium license for each user or capacity add-ons. Microsoft says it will apply those rules strictly from February 2027, so users without the right license won't be able to open some apps. It also stopped selling the per-app license to new customers through some channels in January 2026.
None of this is unfair. But a tool that costs little for eight people can cost real money for 400. Price it at the headcount you expect in two years, not today.
Leaving is the hidden cost
Ask every vendor one question: if we leave, what do we take with us? Usually the answer is your data, plus app designs that only run inside that platform.
OutSystems is unusual. It documents a detach process for OutSystems 11 that hands you standard .NET source code. Read the fine print, though. It covers all your apps at once, you lose the visual tools, and OutSystems calls it "a one-way street."
Appsmith takes a different route. Its core is open source under the Apache 2.0 license, and you can host it yourself. That lowers the risk of a vendor changing its terms.
Who maintains it
Low-code makes building easy. That's the point, and also the risk. Ten departments can build ten apps, each holding its own copy of customer data. When the person who built one leaves, nobody knows how it works. Enterprise platforms ship admin controls for this, but someone still has to decide who may build what.
Limits once the rules get complex
The first 80% goes fast. The last 20% is where projects stall: pricing rules with many exceptions, multi-step approvals, totals that must match finance to the cent. Every platform lets you drop into code for the hard parts. Once most of the app lives there, you are writing custom software inside someone else's walls, often without the testing and change tracking that normal software work gives you.
Customers and partners
Internal tools are the sweet spot. Letting customers in changes the math. Retool prices outside users separately, and only on its higher tiers. Mendix asks customers to classify each user as internal or external for licensing. Microsoft points outside users to a separate product, Power Pages.
A customer-facing app also needs your brand, your speed and your exact workflow. That's where generic building blocks start to show their seams.
Performance and AI
Most low-code apps are fast enough for a team. Some struggle with very large tables, busy screens or many people working at once. Test with your real data volumes before you commit.
Every platform is adding AI features too, from building screens out of a typed request to adding an assistant inside an app. They help you build faster. They help less when you need AI that follows your own rules, with checks and a person approving what matters. That usually takes custom work.
Side by side
| Question | Low-code platform | Custom development |
|---|---|---|
| Best fit | Internal screens over data you already have | Core processes, complex rules, customer-facing tools |
| First working version | Days to weeks | Weeks to months |
| Cost as you grow | Usually rises with every user | Mostly the build and upkeep, not per seat |
| Complex rules | Possible, but harder as they pile up | Built to fit, and tested |
| Customers and partners | Often separate licenses or a separate product | Any audience, fully in your brand |
| If you leave | Your data comes with you, the apps often don't | You own the code |
| Who maintains it | An in-house owner, plus the vendor's updates | Your developers or a partner |
The hybrid path
It doesn't have to be one or the other. Two mixes work well.
Custom core, low-code screens. Put the rules that matter in custom code: pricing, approvals, the link to accounting. Then let an internal team build its own admin screens in Retool or Power Apps on top. The rules stay tested and owned. The screens can change every week without a developer.
Low-code first, custom later. Build version one in low-code to learn what people really need. When it hits the limits above, rebuild the parts that hurt, using the low-code app as a working example of what to build. The trick is to plan the exit on day one. Keep the data in a database you control, not inside the platform.
A made-up example: a 300-person distributor builds a returns screen in Power Apps on top of SharePoint lists. It works well for the six people on the returns team. A year later, sales wants customers to file returns themselves, and credits must reach the accounting system with approval rules by customer tier. The returns team keeps its screen. The customer portal and the credit rules become custom, and both read from the same database.
A second one: a 40-person engineering firm builds a project tracker in Retool over its own database. Two people keep it running, nobody outside the firm logs in, and the rules are simple. It stays in Retool, and that's the right call.
How to decide
Four questions get you most of the way.
Who uses it? Your own staff points toward low-code. Customers and partners point toward custom.
How complex are the rules? If you can explain them on one page, low-code will cope. If finance needs a meeting to explain them, think custom.
Who owns it after launch? Low-code without an owner decays fast. Custom software without a support plan does too.
What does it cost over three years? Add licenses at your expected headcount, the time of whoever maintains it, and the cost of leaving. Compare that with a build plus upkeep. Our guide to custom software vs off-the-shelf runs the same sum for software you buy.
The answers rarely all point one way. Weighing them for your organization is the real decision, and it's worth getting a second opinion before you sign a multi-year license or a build contract.
What most guides miss
The platform is rarely the problem. Most low-code apps that fail do so because nobody owned them, not because the tool was weak.
Where the data lives matters more than where the screens live. Keep your records in a database you control and you can swap tools later. Store them inside a platform's own database and leaving gets expensive.
Seat counts creep. An app built for one team gets shared with managers, then the warehouse, then a contractor. Each new person can be a new license.
Small apps become critical without anyone noticing. Treat any app that touches money or customers as a real system, with backups, access rules and a named owner, whatever it was built with.
How we do it
We start with how your team works today, and if a low-code tool fits, we'll say so. When it doesn't, or only fits part of the job, we build the custom parts and keep your data where you control it, so you can mix tools freely. We also stay on after launch to support and extend the system as your rules and teams change. Tell us what you're weighing.
Sources
- Retool: Pricing
- Microsoft Learn: Licensing overview for Microsoft Power Platform
- Microsoft Learn: Power Apps licensing FAQs
- Microsoft Learn: What is Power Pages?
- OutSystems: The detach process for OutSystems 11
- Mendix Docs: User metering
- Appsmith on GitHub (Apache 2.0 license)
- Appsmith Docs: Self-hosting setup
Facts checked against these sources in November 2026.
