Custom Web Apps vs Low-Code Platforms: A 5-Year TCO Comparison

In year one, low-code is almost always cheaper to stand up. A small internal CRUD app on Retool can ship in a week. A workflow with approvals and a basic UI on Power Platform can be live before a custom engagement has finished discovery. That speed is real, and on a like-for-like prototype the build cost will frequently be 30 to 60 percent lower than a custom equivalent.

The lie is in the scope. Vendor demos almost always show "happy path" applications: a few tables, a couple of forms, a dashboard, role-based access. As soon as the real requirements arrive (complex permissioning, multi-tenant data, audit logging that satisfies SOC 2, performance SLAs, dozens of integrations), the low-code "build" stops looking like configuration and starts looking like custom development inside a proprietary IDE. The year-one budget assumed the demo. The year-one invoice reflects reality.

• Demos cover roughly 20 percent of typical enterprise requirements; the other 80 percent is custom work inside a constrained environment
• Custom builds expose the full cost up front; low-code defers it
• Both approaches need the same discovery, the same domain modeling, and the same UX investment
• Speed advantages shrink quickly as integration count, role count, and data-model complexity grow

“Low-code is cheap until the application becomes worth building. Then it is expensive in ways the procurement spreadsheet did not have a column for.”

This is the single line item that most often flips a five-year TCO comparison. Custom applications, once built, cost what the hosting and maintenance cost. There is no per-user fee. There is no metering on workflow runs. There is no "premium connector" tier. The marginal cost of adding the 50th, 500th, or 5,000th user is essentially zero.

Low-code platforms are sold on a completely different economic model. Power Platform charges per user per month for premium connectors and per-app plans. OutSystems and Mendix price by application size, environment count, and active users, with enterprise tiers easily reaching six figures annually once you cross modest usage thresholds. Retool charges per user, with separate fees for advanced features, audit logging, source control, and SSO. These costs grow with your business; the custom alternative does not.

A realistic five-year picture

1. Year 1: low-code wins on build cost, often substantially
2. Year 2: licensing has now equaled 30 to 50 percent of the year-one custom build cost, every year, forever
3. Year 3: cumulative licensing has often surpassed the entire one-time cost of a custom build
4. Years 4 to 5: licensing continues to compound while the custom application has reached steady-state maintenance

We have walked clients through this exact spreadsheet exercise more times than we can count. The answer is consistent: if the application has more than a few dozen users and a five-year horizon, the licensing line item alone usually justifies a custom build.

When you build a custom application with a modern stack (TypeScript, React, a real database, open-source libraries), you own the artifact. The code is yours, the data is yours, the deployment is yours. If your agency relationship ends, you take the repo and continue. If a library goes out of fashion, you migrate piece by piece. There is no vendor whose business decisions can strand you.

Low-code platforms are the opposite. Your application is expressed in the vendor's proprietary metadata format, runnable only inside their runtime. There is no meaningful "export to code" option that produces a maintainable artifact. If OutSystems raises prices, if Mendix is acquired and the roadmap shifts, if Power Platform deprecates a connector you depend on, you have no exit path that is not a full rebuild. That rebuild cost is the implicit ceiling on what the vendor can charge you, and they know it.

“Custom code is an asset on your balance sheet. A low-code application is a recurring expense whose renewal terms are negotiated annually by the only party who can host it.”

We have helped two clients in the last 18 months migrate off low-code platforms after pricing changes made their current trajectory untenable. In both cases, the migration cost more than the original custom build would have, and the timeline was longer because the team had to reverse-engineer business logic out of visual workflow diagrams to re-implement it cleanly.

The maintenance story is more nuanced than either side admits. Low-code platforms do legitimately handle a layer of patching for you: runtime updates, security patches to the underlying framework, infrastructure upgrades. That has real value, and an honest TCO comparison gives it credit.

But "maintenance" in production means more than patching. It means: when a critical workflow fails at 2am because an upstream API changed its response format, who diagnoses it? On a custom build, your engineering partner or in-house team opens the logs, traces the issue, and ships a fix. On a low-code platform, you open a support ticket and wait for the vendor (or a certified specialist) to triage inside their environment. The platform owns the runtime; you do not own the keys to the basement.

• Custom builds: you pay for maintenance, but you control the response time, the priority, and the fix
• Low-code: the vendor handles runtime patching, but anything in your application logic still requires platform-specific expertise to debug
• Hybrid reality: most enterprise low-code deployments end up paying for both vendor support contracts and a specialist consulting firm

“The vendor will keep the platform running. They will not keep your application running. Those are not the same thing.”

Every low-code platform ships with a connector library: pre-built integrations for Salesforce, SAP, ServiceNow, common databases, common SaaS tools. For applications that live entirely inside that library, integration is genuinely easy. The trouble starts when you need to integrate with something the connector library does not cover, or when the connector covers 80 percent of the API and not the 20 percent you actually need.

At that point, you are writing custom code inside the low-code environment, which is almost always more painful than writing it in a real codebase. You are constrained by the platform's language, its execution model, its debugging tools, and its limits on payload size, request duration, and concurrency. We have seen Power Automate flows that should have been 50 lines of TypeScript turn into multi-screen visual nightmares because the underlying primitives were not designed for the complexity that real enterprise integration requires.

Where low-code platforms typically run out of room

• Complex multi-step transactions with rollback semantics
• High-volume event processing or streaming workloads
• Real-time features (websockets, server-sent events, collaborative editing)
• Custom authentication and authorization models that do not match the vendor's opinions
• Domain logic that requires expressing business rules in real code, not visual diagrams
• Performance-sensitive endpoints where milliseconds matter

For an enterprise web application, hitting one or two items on that list is the norm, not the exception. Hitting four or five is when teams quietly start scoping a custom rebuild. The "cliff" is the moment where the platform's expressiveness runs out and the only remaining option is to model the problem in your head, then translate it into the platform's constraints, paying a complexity tax on every change forever.

This is the cost that almost never makes it into the initial comparison, and it gets worse every year. The labor market for TypeScript, React, and Node engineers is enormous, deep, and well-priced. Every CS graduate, every bootcamp grad, every senior engineer in the open-source ecosystem can be hired or contracted to work on a custom application. Documentation is public, communities are active, AI tooling supports these stacks natively, and the next hire takes weeks, not months.

Certified OutSystems developers, Mendix specialists, and Power Platform consultants are a fraction of the size of that market, charge a premium, and are concentrated at specific consultancies. When your low-code application becomes business-critical, you discover that you are dependent on a small pool of expensive specialists who are mostly employed by partners who also sell implementation services. The vendor benefits from this scarcity; you pay for it.

There is also a more subtle cost: a Power Platform specialist is a Power Platform specialist. Their skill is not portable to the rest of your engineering organization, and engineers who join your team to work on the rest of your stack cannot easily contribute to the low-code application. You end up with a permanent skills silo around every low-code system you operate.

“The talent pool for your stack is part of your TCO. Picking a small pool to save time in year one is a choice you keep paying for in years two through ten.”