Build Decisions
Low-Code vs Custom Web App: Which Should You Build On?
Low-code wins when the workflow is standard, the user count is modest and you need it in weeks. Custom development wins when the logic is unusual, the integrations are heavy, or per-user licensing will outgrow the build cost. The decision is rarely about capability — it is about where your process sits relative to what the platform assumes.
9 min readUpdated
If your process sits outside what the platforms assume, Datanova helps businesses build a custom web application.
What you are actually choosing between
Low-code platforms — Power Apps, Airtable, Retool, Budibase and the rest — give you a working system fast by making decisions on your behalf: the data model shape, the interface patterns, the permission model, the hosting. That is the entire value proposition, and it is also the entire limitation. Everything inside the platform's assumptions is dramatically faster; everything outside them ranges from awkward to impossible.
Custom development makes no decisions for you, which costs weeks upfront and buys you the ability to keep going when the process does something unusual.
The comparison
| Category | Low-code | Custom |
|---|---|---|
| Time to first version | Days to weeks | Weeks to months |
| Upfront cost | Low — often just licences | Five to six figures |
| Cost at 5 years | Licensing, which grows with headcount | Hosting plus maintenance, roughly flat |
| Unusual business logic | Fights you, then blocks you | Whatever the process needs |
| Heavy integrations | Fine with supported connectors, painful without | Any system with an interface |
| Who can change it | Often someone in the business | A developer |
| Performance at volume | Degrades, sometimes abruptly | An engineering problem you can solve |
| Ownership | Your data; the application lives on their platform | Everything, in your repositories |
| Exit cost | High — a rebuild, not a migration | You already have the code |
Where the licensing curve crosses
This is the calculation most teams skip, and it is the one that most often turns out to be decisive. Low-code platforms generally price per user per month. Custom software has a large upfront cost and then a roughly flat one.
So do the arithmetic before choosing, over five years, at the headcount you expect to have — not today's. Multiply your realistic user count by the per-user price by 60 months, add the platform's premium tiers if you will need the connectors or the permissions that sit behind them, and compare that against a build plus maintenance at roughly 15 to 20 percent per year.
When low-code is clearly right
- The workflow is standard — requests, approvals, a form, a list, a status
- The user count is modest and not on a steep growth curve
- You need something working in weeks, and being approximately right beats being exactly right later
- The process is still settling, and you expect to change it repeatedly
- You are validating whether the process deserves software at all
- Your organization already pays for the platform and has someone who knows it
That last case is worth emphasizing. If you already have Microsoft 365 licences and someone comfortable in Power Apps, the effective cost of trying it is close to zero. Try it first. A failed two-week low-code attempt is the cheapest possible way to learn exactly which constraints your process breaks.
When it will not hold
- The business logic is genuinely unusual — pricing rules, allocation, scheduling with real constraints
- You need two-way sync with a system the platform has no connector for
- Permissions vary by role, region, customer and record, rather than by role alone
- The data volumes are large enough that the platform's limits are in sight
- You have compliance obligations requiring audit history and retention the platform does not guarantee
- The application is the product, or is close enough to it that being on someone else's platform is a strategic risk
How to decide without a six-month evaluation
- Write down the three most unusual things your process does. If a platform cannot do them in its native model, it is not a fit — connectors and scripts that work around the model are how low-code projects become unmaintainable.
- Do the five-year licensing arithmetic at your expected headcount, not today's.
- Build the hardest screen, not the easiest one. Prototypes that start with the simple form prove nothing.
- Ask what leaving costs before you commit. If the answer is a full rebuild, that is a real number in the comparison.
- Prefer the reversible choice when it is close. Low-code you outgrow is a rebuild you can plan; custom software you did not need is money already gone.
Frequently asked questions
Is Power Apps good enough to replace a business spreadsheet?
Is Airtable a database?
Can we start with low-code and move to custom later?
Which is cheaper overall?
Not sure which side your process falls on?
In a free consultation we look at the three things your process does that are genuinely yours, and tell you whether a platform will hold them — including when the answer is to try low-code first and not pay us anything.