The short answer: low-code vs custom development
Low-code platforms such as Microsoft Power Apps, Retool and Bubble let people assemble working apps from visual building blocks, with the platform handling hosting, sign-in and updates. Custom development means engineers write the application in code (for example, React screens, REST APIs and a SQL Server database), and you, or the team you bring in, host and maintain it.
Neither is better in general. It depends on who uses the app, how complicated its rules are, how much data it handles and what it connects to. A purchase-request form for 15 office staff and a job app for 300 outside technicians are different problems, even on the same platform.
Signs your low-code app is starting to creak
- Someone exports data to a spreadsheet every week because the report you need can’t be built inside the app.
- Screens that used to load quickly now hang, or searches quietly return incomplete results.
- Every new crew, site or customer group starts a conversation about licenses.
- “Can the subcontractors use it?” gets a complicated answer.
- The app needs data from a system the platform has no connector for, so someone re-keys it.
One of these is usually fixable inside the platform. Several, on an app the business depends on, are the sign that low-code isn’t enough for that app anymore and it’s time to compare options.
What low-code platforms like Power Apps, Retool and Bubble do well
Low-code earns its place when speed matters more than precision and the people who know the process can build the first version. It does well in four situations:
- Proving a process. If the process still changes every week, a working low-code app in front of real users is an inexpensive place to let it settle.
- Simple internal workflows. Request forms, approvals, checklists and trackers with a few screens, a few roles and one data source.
- Apps inside tools you already pay for. If your company runs on Microsoft 365, a Power Apps form on top of a SharePoint list may not need a new vendor at all.
- Admin screens over data you already have. Retool is built for internal tools that connect to your existing databases and APIs.
Bubble sits slightly apart: it builds complete web apps with their own database, including apps your customers use. We build in Bubble and Webflow as well as in custom code, so this guide isn’t a case against low-code.
A low-code version keeps its value even if you move to custom later: every screen, field and rule in it is a working specification of how your team does the job.
Where low-code apps hit their limits
Low-code platforms are designed around common cases. The limits show up when your app stops being one: more users, outside users, stricter rules, more data, more systems.
Per-user licensing at scale
Low-code pricing is often tied to the number of people who use the app, not only the people who build it. That’s easy to justify for 12 office staff. It’s a different conversation when operations says, “Our contractors need to do this from their phones.”
For outside users, Microsoft’s documentation on sharing a canvas app with guest users explains that guests are added to your Microsoft Entra tenant, and a guest who doesn’t already have a license in their own organization needs one assigned.
Example (hypothetical, not client data)
A facilities services company built a work-order app for 12 dispatchers. Leadership now wants 90 technicians and 40 subcontractor techs using it from their phones. If every user needs a paid seat, the license count goes from 12 to 142, and the subcontractors need accounts in the company’s directory. Put your real per-user quote into the build vs buy software calculator to compare that with a custom build.
Permissions that depend on the record
Simple roles, like “staff submit, managers approve”, fit almost any platform. Operations rules often go further: subcontractors see only their own jobs, supervisors see their region, finance sees costs but can’t edit the job, and each customer sees only their own sites.
Check where each rule is enforced. If a rule lives only in a screen filter, it hides records on that screen, but anyone with access to the underlying list or table may be able to reach them another way. Rules like these belong in the data layer, enforced on the server, with a record of who changed what.
Data volume: slow screens and incomplete results
As records pile up, what matters is whether the platform filters data in the database or pulls it into the app first. Microsoft’s delegation overview explains that when a query can’t be delegated to the data source, Power Apps retrieves only the first 500 records (adjustable to a maximum of 10,000) and works on those, so a search over a larger table can return incorrect results.
Whatever the platform, test it: load a realistic copy of a few years of your data and time the searches and reports your team runs daily.
Integrations beyond the built-in connectors
Built-in connectors handle common systems well. Trouble starts with an older system that has no connector, a two-way sync where both sides can edit the same record, or a nightly job that must never skip records silently. Those need error handling, retries, logging and failure alerts, which are hard to do well in visual workflow steps.
If re-keying is the real problem, see how to eliminate double data entry; connections that need code are API integration work.
Changes made live, by one person
Low-code makes changes easy, until the one person who understands the app edits the version everyone is using mid-shift. Ask whether your platform gives you a test environment and version history, whether anyone uses them, and who could fix the app if its builder left. Our guide to employee-built apps covers how to bring apps like this under proper ownership.
Your first call is with an engineer
Tell us what the app does, who uses it and where it’s creaking. An engineer will look at whether a fix on the platform will do, or whether part of it should move to custom code.
Licensing and lock-in: questions to ask before you build (or keep building)
Ask these before you put a business-critical process on a platform, and again before each renewal.
Licensing questions
- Who needs a license? Builders only, or everyone who opens the app? Do occasional, read-only and outside users count?
- Which features move you up a tier? Microsoft’s Power Platform licensing overview says the Power Apps rights included with some Microsoft 365 licenses are intended for Microsoft 365 data and standard connectors, and don’t provide the same rights as standalone premium licenses. The SQL Server connector, for example, is listed as Premium for Power Apps.
- What’s metered besides seats? Storage, automation runs, API calls and extra environments can each carry their own limits or charges.
- What happens at renewal? The same Microsoft overview notes that, effective January 2, 2026, the Power Apps per app license is no longer available to new customers through some purchasing channels. Ask what your plan becomes if the tier you’re on is retired.
Lock-in questions
- Can you export all your data? Every table, the IDs that link records, uploaded files and history. Bubble’s manual says database data can be exported as CSV, JSON or newline-delimited JSON. Run a trial export now, not on the day you decide to leave.
- Can you export the app itself? Bubble’s application and data ownership page states that Bubble apps can only be run on the Bubble platform and can’t be exported as code. Retool’s migration guide exports apps as JSON for import into another Retool instance. Either way, leaving means rebuilding the screens and logic; the data is what moves.
- Whose account is it on? An app on a former employee’s personal account or credit card is a business risk. A company account should own the app, the data and the billing, with at least two admins.
- Where is the logic written down? Formulas and workflow steps scattered across screens are the hardest part of any move. A plain description of each rule makes a later rebuild much easier to scope.
Lock-in is a trade, not a verdict
Low-code ties you to a vendor’s pricing, limits and roadmap. Custom code ties you to whoever can maintain it, unless the code repository, hosting accounts and documentation are in your company’s name. Either can be the right call if you make it knowingly.
Custom development: what you get and what you take on
The trade is the reverse of low-code: more control, and more responsibility.
What you get
- Your process, not a template. Screens for each role, including phone screens for the floor and the field. This is the answer to “We need software that follows our specific process.”
- Permissions enforced on the server. Rules like “subcontractors see only their jobs” live in the data layer, not in a screen filter.
- No per-seat platform license. Adding 200 contractors adds hosting load and support work, not 200 platform seats.
- Data in a database you control. For example, a SQL Server database that reporting tools such as Tableau can read directly.
- Integrations built for your systems. Connections to other software through their APIs, with logging, retries and alerts built in.
For example, we built a custom manufacturing data-management application for Chelten House Products, a fourth-generation food manufacturer (sauces, dressings, condiments). Operators record production performance, product traceability and equipment downtime. The app distinguishes planned from unplanned downtime, records causes and durations, has administrative controls, and stores data in SQL Server that supports their Tableau reporting.
What you take on
- An upfront build. You pay for design and development before the first version is in use, and a first release takes longer than a low-code prototype.
- Hosting, security updates and backups. Someone has to patch, monitor and back up the application. Our maintenance and support page covers what that involves.
- Changes go through developers. A power user can’t tweak a screen on Friday afternoon, so you need a simple way to request, test and release changes.
- A team you can reach. Custom software is only as good as your access to the people who understand it. How to choose a software development company covers what to check.
We live with this trade ourselves. Besides client work, we design, engineer and still run our own product, Just A Menu, used by restaurants across the U.S. For the broader version of this decision, see custom software vs off-the-shelf.
The middle path: keep the low-code screens, move the heavy part
If the screens work but the data or integrations don’t, keep the low-code front end and move the heavy part into code: a proper database, an integration service or a reporting feed. Low-code tools can generally read and write an external database or API, so users keep the screens they know. Check licensing first: connecting Power Apps to SQL Server uses a Premium connector.
Moving from a low-code app to custom without losing your data
Moves go wrong when the data is an afterthought or the old app is switched off too early. This order keeps both risks small:
- Inventory what the app really does. List every screen, field, formula, automation, scheduled job and email, and who uses each one.
- Export the data before anyone writes code. Pull every table, the IDs that link records, uploaded files and any history fields. Check that the export opens, links up and matches the record counts in the app.
- Design the new database and map old fields to new. Decide what to clean up (duplicates, free-text fields that should be pick lists) and write the mapping down.
- Rebuild the workflows that matter first. Start with the ones people use every day. Screens nobody has opened in months may not need rebuilding at all.
- Rehearse the migration. Load a full copy of the data into a test environment, have real users run their real tasks, and repeat until the numbers reconcile.
- Run both, then cut over. Keep the old app running while the new one proves itself, set a short freeze window for the final data load, then make the old app read-only.
- Cancel the old subscription last. Keep read-only access until at least one full reporting cycle has closed in the new system.
Example (hypothetical, not client data)
An equipment rental company has outgrown the Bubble app it uses to track check-out and return inspections, with photos. Before rebuilding, the team exports every data type, confirms the photos download with their inspection IDs, and finds three automations nobody had documented: late-return emails, a damage-fee calculation and a weekly utilization report. Those three become requirements for the new app, and the Bubble app stays read-only for a month after cutover.
If the app began as someone’s side project and now runs a real process, see prototype to production.
Decision table: stay on low-code, extend it or go custom
Go row by row for your app. Mostly the middle column: stay and tidy up. A mix: consider the middle path above. Mostly the right column: plan the move.
Then put numbers on it: the build vs buy software calculator compares subscription costs with a custom build over one to ten years, using your own quotes. If custom wins, see how we approach internal tools development, or browse more guides on the decisions that come next.