Enterprise Apps: Build vs Buy vs Low-Codein 2026

"Low-code is $20 a user. Your quote is six figures. Help me understand why I'd ever pay you."

That's a paraphrase of an operations director on a call with me. It's a fair question, and it deserves arithmetic rather than a sales answer. So I went and checked what the major platforms actually charge today, on their own pricing pages, on September 30, 2026.

Here's the short version. Sometimes she shouldn't pay us. For an internal app used by fifty people, three years of Power Apps Premium licences come to about $36,000, and I can't build and support anything for that. For the same app used by three hundred people, the licences alone come to $216,000, and the math tilts the other way.

The $20 is real. What it gets multiplied by is the whole argument.

This piece is the three-way version of that conversation: build custom, buy a SaaS product, or build on a low-code platform. It has current prices, the arithmetic done in the open, and a section most comparisons skip, which is what each path costs you on the day you want out.

If you want the startup version of this debate (Bubble, FlutterFlow, Lovable, a founder with an MVP), our older piece on low-code vs custom development covers that ground. This one is for enterprise buyers with seat counts, security reviews and procurement.

The usual framing treats this as one decision. It's actually a sorting exercise, repeated for every app you run.

The belief a competent person holds goes like this: pick a strategy. Either you're a "buy first" shop, or a "Microsoft shop" that does everything in Power Platform, or an engineering company that builds. Then apply it consistently.

It doesn't hold, because the three paths have completely different cost shapes. SaaS and low-code are cheap to start and charge you per person, forever. Custom is expensive to start and nearly flat per person after that. Those are two different curves, and they cross.

Think of it like renting versus buying a car. Renting is obviously right for a weekend trip and obviously wrong for a daily forty-mile commute over five years. Nobody picks a "rental strategy" for their whole life. They look at how much driving they'll do.

So the question isn't which path your company believes in. It's how many people will use this particular app, for how long, and how different it has to be from what every other company runs. Answer those three for each app, and the path mostly picks itself.

Therefore:most enterprises should end up running all three. Payroll bought. The approvals app for the facilities team on low-code. The customer-facing platform built. That's not indecision. It's the correct answer applied three times.

Let me pin down the words, because vendors blur them on purpose.

For the broader picture of what enterprise mobile apps need to connect to (Salesforce, Teams, Workday), see our guide to enterprise app solutions. This article stays on the money and the exit.

Every figure below comes from the vendor's own pricing or documentation page, checked September 30, 2026. Where a vendor publishes no price, I write "not publicly disclosed" and stop there.

A few things in that table deserve a sentence each.

Here's the arithmetic for one app, 300 employees, 36 months, at list price. Every line is a labelled scenario, not a quote.

Consider a company with 300 people who'll use one internal operations app: approvals, a few dashboards, data pulled from two existing systems. That's the most common shape of enterprise app request I see. I'll price it every way the published numbers allow.

The custom lines use our own published bands: a multi-workflow platform with system integration at $70,000 to $180,000, and a support retainer at $2,500 to $9,500 a month. I've paired low with low and high with high, which is roughly how scope and support move together.

Now the part the table doesn't include, which is people.

Low-code licences don't build the app. Somebody inside your company does, and then maintains it. The BLS puts the median annual wage for software developers at $135,980 for May 2025. Suppose half of one developer's time goes to this app for three years. That's $135,980 x 0.5 x 3 = $203,970 in wages alone, before benefits and overhead.

Add that to scenario A and the low-code path is about $420,000 over three years ($216,000 + $203,970). The custom low-end path is $160,000, and our retainer already covers the maintenance. That's a ratio of about 2.6x.

To be clear, that comparison flatters custom in one way I should admit. The retainer covers changes we make; if your business wants to change the app every week without a ticket, the half-developer is doing something a retainer doesn't. And custom hosting isn't in my figure at all. For a 300-user internal app it's usually small next to these numbers, but it isn't zero, and I didn't price it.

It also flatters low-code in one way. Scenario C prices Retool Business, but if your security team needs SSO and audit logs, the tier that lists them has no published price. The real Retool figure is $171,000 plus an unknown.

What about "buy"?There's no honest single price for buying, because it depends which product fits your process. The formula is the same as Salesforce's: seats x monthly price x 36, plus implementation. Salesforce Platform is the closest published proxy here, and scenarios E and F show how wide one vendor's own range is. Going from Starter to Plus multiplies the three-year bill by 4x, and the trigger can be as mundane as needing an eleventh custom object.

If you need the in-house labor side of this worked properly, our sibling article on the cost to hire a mobile app developer goes through salary, contractor and agency rates in detail.

If you remember one variable from this article, make it the number of users in year three.

Here's the same app at four sizes. Low-code columns are three years of licences at list price; the custom column is the low-end scenario G, which doesn't move with users except for hosting.

The arithmetic behind the Retool column is (users x $15 + 5 x $50) x 36. At 50 users that's (750 + 250) x 36 = $36,000. At 1,000 it's (15,000 + 250) x 36 = $549,000.

Now reduce it to a multiplier. Power Apps Premium and a low-end custom build cross at 160,000 / (20 x 36) = about 222 users. Below that, the licences are cheaper than the build. Above it, they aren't, before you count anyone's salary.

For Retool Business, the crossover is where (users x 15 + 250) x 36 = 160,000, which works out to about 280 users.

So why is the question important? Because most internal apps start small and nobody reruns the numbers when they spread. The expense-approval app built for one department in year one is used by the whole company in year three, and the licence line has quietly tripled.

And the reverse is true. A 40-person team app should almost never be custom. At that size the licence bill for three years is less than a single sprint of senior engineering time, and I'd tell you so on the call.

Every path has an exit cost. It's just that only one of them shows up on the first invoice.

Economists call this a switching cost: the price of changing suppliers, which the incumbent supplier knows about and you mostly don't think about until renewal. It's the reason your phone company used to make porting your number painful. The price of leaving is part of the price of staying, because it sets how much the vendor can raise prices before you walk.

Price the exit as a number.Suppose leaving the low-code platform in year four means rebuilding the app custom at the low end of our band: $70,000. Spread over the three years you used the platform, that's about $23,300 a year of hidden liability sitting behind the licence line. Put it in the spreadsheet next to the licences, and the comparison gets honest.

The same logic applies to our side. A custom build is only low lock-in if the contract actually assigns you the code and the IP. Ours does. Plenty don't, and an agency that keeps the IP has simply become a more expensive SaaS vendor.

Run each app through these seven questions. Whichever column collects most of your answers is your starting point.

It's a starting point because two questions override the rest.

And a few shortcuts from what I see most often:

• Buy: Payroll, expenses, IT ticketing, standard CRM, anything where you'd happily copy a competitor's process.
• Low-code: Departmental approvals, inspection forms, admin panels over an existing database, apps where the data already lives in Microsoft or Salesforce and users number in the dozens or low hundreds.
• Build: Customer and partner apps, mobile apps for field staff at scale, anything tying several legacy systems together, and anything regulated where you need to design and evidence the controls yourself.
• Hybrid: A custom core with a low-code admin panel on top is common and sensible. Retool over your own database is a good example: cheap for the ten people in operations, while the customer-facing app stays in code you own.

If one of the systems you'd need to integrate is old enough that nobody wants to touch it, read our piece on legacy system modernization before you choose. Integration difficulty tends to push toward build, because low-code connectors for old systems are where platforms are thinnest.

Here are two of our own projects, described only by what the case studies say was built. I'm not repeating their outcome figures, because I can't verify them independently and this article holds itself to that line.

To be fair to the other side: neither case study is evidence that custom always wins. They're two apps where the requirements pushed hard toward it. I've also told enterprise callers to put their departmental form on Power Apps and not hire us, and I'll keep doing that.

Some of the most repeated numbers in this debate are ones I couldn't trace, including two on our own site.

Our older low-code article carries a statistic that 65 percent of pure low-code projects need a rewrite within 24 months, attributed to a "benchmark" with no link, and a low-code market size credited to a Gartner forecast with a link to Gartner's homepage. I looked for a primary source for the rewrite figure and couldn't find one. I don't repeat either here, and I wouldn't rely on either one. That's an admission about our own work, and it belongs in this article more than anyone else's mistake does.

I also don't print estimated prices for OutSystems, Appian, Retool Enterprise or Mendix Premium. Several comparison blogs publish confident ranges for them. None I found shows a contract or quote. A made-up figure in your budget spreadsheet will anchor your negotiation to someone else's guess.

And I don't quote vendor-published productivity multipliers ("build apps 10x faster") as fact. They come from the vendor, measured by the vendor, on projects the vendor chose. They might be true on those projects. They aren't evidence about yours.

Whichever path you're pitched, these are the signs the numbers won't hold.

• A new tenant priced on the Power Apps per app plan: Microsoft ended sale to new customers from January 2, 2026. The proposal is stale or the partner hasn't checked.
• A low-code quote that prices the tier without SSO and audit logs: If your security team requires them, price the tier that includes them, even if it's quote only.
• Licences quoted for year one only: Ask for three years at your expected year-three seat count.
• No builder or maintainer in the low-code budget: The platform doesn't build the app. Someone's salary does.
• A custom quote with no maintenance line: Year two costs money. Ask what the retainer or support model is.
• An agency that keeps the IP: Then you've bought SaaS with extra steps. Get the assignment clause in writing.
• A SaaS deal with heavy customization: If the implementation budget rivals a build, you're building on someone else's product without owning the result.
• No answer to 'what does leaving cost?': Every vendor should be able to describe its export and termination process in writing.

Let me argue against myself, because the framework has real failure modes.

Your negotiated prices could be much lower than list. Large Microsoft and Salesforce customers rarely pay list. If your enterprise agreement already includes Power Apps rights through another bundle, the marginal licence cost might be close to zero and low-code wins at almost any seat count. Rerun the crossover with your actual price. If that flips the answer, the answer should flip.

A custom build can overrun. Scenario H exists for a reason. A vague scope turns the low band into the high band, and then the crossover moves past 700 users. The protection is a fixed-price phased proposal with a scoped first phase, which is how we quote, but it only protects you if the scope is written down.

You might not have anyone to own a custom app.A codebase with no owner rots. If there's no retainer and no internal engineer, a low-code app that the business can edit is safer, even if the spreadsheet says otherwise.

Vendors reprice. Microsoft retiring the per app plan is a live example of a pricing change that moved thousands of budgets. The same can happen in your favor or against you during a three-year term, which is one more reason to prefer contracts with price caps on renewal.

Why is the framework still worth using? Because the worst case is bounded. If you misjudge and put an app on low-code that outgrows it, your exit cost is roughly a custom rebuild, which you'd have paid anyway on the build path. If you misjudge the other way and build something small, you've overspent by the difference between a build and a few years of licences. Neither is a disaster. Not doing the arithmetic at all is how companies end up paying for both.

Here's what I checked, and what I couldn't.

• List prices only: Everything here is published list pricing on September 30, 2026. Enterprise discounts, bundles and multi-year deals are invisible to me.
• Quote-only tiers: OutSystems, Appian, Retool Enterprise, Mendix Premium and Salesforce's higher tiers aren't priced. Their absence from the arithmetic is a gap, not a zero.
• Custom hosting: I didn't price hosting for the custom scenarios. It varies too much by architecture to state as one number.
• Labor assumption: The half-developer figure is an assumption to show the method, using the BLS national median wage. Your team's real allocation could be much higher or lower.
• OutSystems detachment: The ODC claim comes from community experts on the OutSystems forum, not from OutSystems. Ask the vendor.
• Currency and region: All prices are USD as shown on US pages. Other regions may differ.
• Our own bands: The custom figures are Frenchy Digital's published bands. Other agencies price differently, and you should get more than one quote.

You can sort your app backlog into the right buckets in about a week.

1. 1.List every app request on the table and write two numbers next to each: expected users in year three, and whether it's how you compete (yes or no). That alone sorts most of them.
2. 2.For anything headed to low-code, get a written three-year quote at the year-three seat count for the tier that includes SSO and audit logs, and add a builder's time at a real salary. For anything headed to build, get a fixed-price phased quote with a maintenance line and an IP assignment clause.
3. 3.Ask every vendor, in writing, what leaving costs: export format, what the export excludes, and termination terms. Put the rebuild estimate in the spreadsheet as a line of its own.

For AI-specific versions of the same decision, our piece on build vs buy for AI agents runs the parallel argument. Then open the spreadsheet. Time to count seats.