Custom Build vs Low-Code (Retool, Bubble): Which One Should You Actually Fund?
Reach for low-code when the app is an internal tool or an early product you need live in weeks, and reach for a custom build when the app is the product itself and has to scale, integrate deeply, or run for years. Retool starts free and runs $10 to $50+ per user per month; Bubble runs $32 to $475+ per month by plan; a real custom build starts around $40k and climbs from there, but you own the code outright. The trap is defaulting to low-code because it is fast, then hitting the platform's ceiling right as the product starts to matter.
What is the real difference between a custom build and low-code?
Low-code platforms like Retool and Bubble give you a visual builder and a hosted runtime. You assemble screens, wire up logic, and connect data sources without writing most of the code yourself. Retool is built for internal tools that sit on top of your databases and APIs. Bubble is built for public-facing web apps with its own visual data layer and workflow engine. Both get you to a working app dramatically faster than starting from an empty repository.
A custom build is code your team or an agency writes and owns. There is no platform between you and the machine. Every layer, the database, the API, the frontend, the hosting, is yours to shape and yours to maintain. Nobody else prices it, sunsets features on it, or holds your runtime hostage.
The decision is not really about how fast you can ship a first version. Low-code always wins that race. It is about what happens at month twelve, when the app has real users, real data, and requirements the visual builder was never designed to handle. Across 2,000+ projects, the pattern is consistent: low-code shines for internal tools and prototypes, and strains once an app becomes a core product with its own roadmap.
How do custom build and low-code compare on the criteria that matter?
| Criteria | Low-code (Retool, Bubble) | Custom build |
|---|---|---|
| Cost | $10 to $475+ per month by plan and seats | $40k+ up front, plus hosting and upkeep |
| Speed to live | Days to a few weeks | 2 to 6 months for a production build |
| Control | Bounded by what the platform exposes | Total, down to every line and dependency |
| Scalability | Fine to mid-scale, then platform limits bite | Yours to architect for any load |
| Fit to your workflow | Good until you need what the builder cannot do | Exact, the code adapts to you |
| Lock-in | High, your app lives inside their platform | None, you hold the source |
| Maintenance | Platform handles infra, you handle the app | Yours entirely, budget 15 to 20% a year |
| Best for | Internal tools, admin panels, fast MVPs | Core products that must scale and endure |
What does low-code actually cost, and where do the limits sit?
The published pricing is where low-code looks most attractive and where the ceiling first shows. Retool has a free tier for small teams, then paid plans that run roughly $10 per standard user and $50 per business user per month, with self-hosted and enterprise options above that. Bubble prices by plan rather than seat: a Starter tier around $32 per month, Growth around $134, and Team around $475, each with workload and capacity limits that throttle heavier apps.
Those numbers stay small until the app grows. Bubble meters compute through workload units, so a busy app can force an upgrade or run into capacity ceilings on a lower plan. Retool's cost climbs with every builder seat, and complex apps push you toward the pricier business and enterprise tiers. Neither is a bad deal for what it is. The point is that the monthly bill is real, it compounds with usage and seats, and you never own what you are paying for.
| Scenario | Low-code (3-year total) | Custom build (3-year total) |
|---|---|---|
| Internal admin tool, small team | $0 to $12k | $40k to $90k, rarely worth it here |
| Early product MVP, growing usage | $5k to $30k | $60k to $150k, break-even territory |
| Core product at scale | $30k to $120k+ and still not owned | $120k to $350k plus ~18% a year upkeep |
Who is low-code genuinely best for?
Low-code is the right call more often than founders expect, because most of what a business needs to build is not its differentiator. If the app supports the operation rather than being the operation, a visual builder usually wins.
- Internal tools and admin panels. This is Retool's home turf. A dashboard that reads three databases, lets ops staff edit records, and triggers a few API calls is exactly what it was built for, and rebuilding that from scratch is hard to defend.
- Early MVPs that need to prove a market. Bubble can get a real, usable product in front of users in weeks. When you are testing whether anyone wants the thing, spending six figures on a custom build first is capital frozen before the business is proven.
- Non-technical teams shipping without engineers. When there is no development team to hand a codebase to, a platform that a product person can maintain is a genuine advantage, not a compromise.
- Low-traffic, bounded-scope apps. A form-heavy tool for a few hundred internal users will likely never hit the platform ceilings that break larger apps.
For these cases, paying an agency to write custom code is spending months and tens of thousands to own a problem the platform already solved for a few hundred dollars a month.
When is a custom build the honest recommendation?
Custom wins when the app is the product, when it has to scale past the platform's comfort zone, or when the requirements outgrow what a visual builder can express. The test: is this app your competitive edge, and does it need to run and grow for years? If yes, low-code becomes a cage rather than a shortcut.
- The software is the business. If your app is what customers pay for, building it on a platform that prices, throttles, and can sunset features on you means your core product sits on someone else's terms.
- You need real scale or performance. Bubble's workload metering and shared infrastructure work against high-traffic, compute-heavy apps. A custom stack lets you architect for the exact load you expect.
- The logic gets genuinely complex. Deep integrations, intricate business rules, custom algorithms, or fine-grained security models are where visual builders start requiring so many workarounds that you lose the speed advantage entirely.
- Lock-in is a real risk to the business. A Bubble app cannot simply be exported and rehosted elsewhere; leaving the platform means rebuilding. When the app is critical and long-lived, owning the source is worth the up-front cost.
In these cases the up-front spend buys something low-code cannot sell you: an asset you own, a stack with no per-seat or per-workload tax, and a product no platform decision can undercut.
What does low-code lock-in actually cost you later?
Lock-in is the trade-off buyers underweight most. A Bubble app is not portable code you can lift and drop onto your own servers; its logic lives inside Bubble's editor and runtime. A Retool app is coupled to Retool's platform even when it talks to your own databases. If pricing changes, if a limit blocks you, or if the platform's direction stops matching yours, your options are to pay more or rebuild from scratch.
This is not a reason to avoid low-code. It is a reason to be honest about what stage the app is in. For an internal tool or an unproven MVP, lock-in barely matters, because if the app fails you lose little, and if it succeeds you will have learned enough to rebuild deliberately. For a core product you intend to run for years, starting on a platform you cannot leave without a rewrite is a cost you pay in the future, and it is usually larger than the custom build you avoided up front.
Can you start on low-code and move to custom later?
Yes, and this staged path is often the smartest route, not a failure. Prove the idea on low-code, then rebuild the parts that matter once the requirements are real and validated. The mistake is treating the platform as permanent when it was only ever meant to get you to certainty faster.
- Prototype on low-code deliberately. Use Retool or Bubble to validate demand and learn what the app actually needs to do, rather than guessing the full spec before anyone has used it.
- Watch for the ceiling signals. Rising workload costs, features you cannot build without ugly workarounds, and performance complaints are the platform telling you the app has outgrown it.
- Rebuild the core, keep the periphery. When you move to custom, migrate the differentiating product first. Internal admin tools can happily stay on Retool indefinitely.
- Plan the migration before you are forced into it. Moving off a platform under duress, mid-outage or mid-price-hike, is far more expensive than a planned rebuild while the low-code version still works.
Done this way, low-code earns its keep as a validation engine and a permanent home for internal tools, while custom code takes over exactly where ownership and scale start to matter. That sequence is almost always cheaper than committing to either extreme on day one.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- Organizations that scaled intelligent automation report an average cost reduction of 32% (up from 24% in 2020), and respondents expect an average 31% cost reduction over the next three years. Source: Deloitte (2022) →
- In PMI's 2014 Pulse of the Profession report on requirements management, inaccurate requirements management is cited as a leading cause of project failure, with 47% of unsuccessful projects failing to meet goals due to poor requirements management. Source: Project Management Institute (PMI) (2014) →
- Across more than 5,400 IT projects studied by McKinsey and the University of Oxford BT Centre, large IT projects ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Source: McKinsey & Company / University of Oxford (BT Centre for Major Programme Management) (2012) →
- Large companies globally have captured, on average, only 31% of the expected revenue lift and 25% of the expected cost savings from their digital and AI transformations - a significant gap between expected and realized value. Source: McKinsey & Company (2023) →
Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.
Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
Is a custom build always more expensive than low-code like Retool or Bubble?
Up front, yes. Low-code starts free to a few hundred dollars a month, while a real custom build starts around $40k. But low-code cost compounds with seats and usage, and you never own the app. For an internal tool or unproven MVP, low-code is far cheaper and the right call. For a core product at scale, three years of platform fees plus a forced rebuild later can exceed the custom build you would have owned outright.
When should I build custom instead of using low-code?
Build custom when the app is your product, has to scale past the platform's limits, or involves logic a visual builder cannot cleanly express. The test: is this app your competitive edge, and does it need to run for years? If yes, low-code becomes a cage. If the app merely supports your operation and serves a bounded audience, low-code almost always wins.
How much do Retool and Bubble actually cost?
Retool has a free tier, then paid plans around $10 per standard user and $50 per business user per month, with self-hosted and enterprise options above. Bubble prices by plan rather than seat: Starter around $32 per month, Growth around $134, and Team around $475, each with workload and capacity limits. Both stay cheap at small scale but climb with seats and usage, and neither gives you ownership of the app.
What is low-code lock-in and how much does it matter?
Lock-in is that your app lives inside the platform and cannot be exported as portable code. A Bubble app cannot be lifted onto your own servers; leaving means rebuilding. It barely matters for an internal tool or a throwaway MVP, where you lose little if the app fails. It matters a great deal for a core product you plan to run for years, because escaping the platform later means a full rewrite you pay for on their timeline, not yours.
Can I start on low-code and move to a custom build later?
Yes, and it is often the smartest path. Prototype on Retool or Bubble to validate demand and learn the real requirements, then rebuild the parts that matter once the idea is proven. Watch for ceiling signals like rising workload costs, needed features you cannot cleanly build, and performance complaints. Migrate the differentiating product to custom code first, keep internal tools on the platform, and plan the move before a price hike or limit forces it.