Internal tools in 2026: Retool, Lovable, or a real engineer?

Your ops team spends 11 hours a week in a spreadsheet that should be an app. Five tabs deep, conditional formatting holding it together, three people editing it at once, formulas breaking every Tuesday. You've been promising to fix it for a year. What you haven't decided is who builds it.

In 2026, there are three credible answers: a low-code platform like Retool, an AI builder like Lovable or Bolt, or a senior engineer writing real code. Each works for a different shape of problem. Each has a cost curve that bites at a different point. Pick the wrong one and the spreadsheet becomes a worse spreadsheet with extra steps.

The three options, honest version

Retool (and Appsmith, Internal, Tooljet)

You wire components to a database, write a bit of JavaScript, and you have a CRUD app by Friday. The strength is speed for a familiar shape: tables, forms, buttons, queries against an existing database. The weakness shows up when you need anything off the rails: custom UX, complex permissions, logic that lives outside the platform, or a screen a customer will see. Retool is excellent for the 80% of internal tools that look like a spreadsheet with auth.

Lovable, Bolt, v0 and friends

You describe the app in English, the AI ships a Next.js app, you tweak the prompt until the screens look right. The first version is genuinely impressive and arrives in an afternoon. The trouble is version three: when ops asks for a permissions model, an audit log, and a bulk import, the AI rewrites half the codebase and breaks two screens you forgot to test. Without someone who can read and edit the generated code, you've built a prototype that pretends to be a product.

A senior engineer writing real code

Two to four weeks of focused work produces a Next.js or Astro app with your auth, your styling, your data model, and tests. The first version takes longer than Retool or Lovable. Every version after that takes less, because the codebase is normal code you can hand to any engineer. The catch is staffing: this only works if you have an engineer who'll still be around in six months, in-house or through an agency.

Cost over three years

Vendors price the first month, not the third year. Here's the real cost shape for a typical internal tool with 25 users.

* Lovable / Bolt year-one cost assumes hiring a developer for two weeks to harden the generated code; without that, costs look lower but the tool dies at v3.

The crossover is consistent: under 18 months, low-code wins. Past 24 months, custom is cheaper in total. Lovable and Bolt sit awkwardly in the middle because the "build" is free but the "make it last" cost is the same as building from scratch.

What each option is actually good at

The traps in each option

Retool's hidden lock-in

Retool's logic lives inside Retool. Every business rule you encode is a rule you can't run anywhere else. After two years, "migrating off Retool" means rewriting from scratch because there's no codebase to port. Treat it as a permanent dependency, not a stepping stone. If you might outgrow it, design your data model in your own database so at least the data is portable.

Lovable and Bolt's v3 cliff

The first two versions of an AI-built app are great. Around v3, the codebase gets large enough that the AI can't hold it all in context, and every change starts breaking unrelated screens. We've seen this on multiple client projects; we wrote a full playbook for getting unstuck. The fix is always the same: someone has to own the actual code. If that someone doesn't exist, you've bought a prototype, not a product.

Custom build's staffing trap

The reason custom builds get a bad reputation isn't that they cost more; it's that companies build them and then have nobody to maintain them. The engineer who built it leaves, and a year later the codebase is a mystery. Avoid this with two practices: write a README that explains the data model in 30 lines, and lock in a maintenance retainer (typically 10-15% of build cost per year) with whoever wrote the code.

A decision checklist that fits on a sticky note

• Audience under 10 people, lifespan under a year: Retool or Airtable. Don't overthink it.
• Not sure what the tool should do yet: Lovable or Bolt to explore, set a two-week budget, throw it away after.
• Multi-tenant, customer-facing, or core to revenue: Custom. The 3-year math always wins.
• No engineer to maintain anything: Retool with a maintenance retainer. Custom is a trap without staffing.
• The tool replaces a spreadsheet 25 people fight over daily: Custom. Spreadsheets at that scale are the bottleneck on three other things.

On Savi projects we build a lot of these. DropTaxi started as a custom internal dispatch tool and grew into the multi-tenant SaaS it is today. ZestAMC replaced four spreadsheets and a Retool dashboard with one app that now runs against $10M+ in assets. The pattern is the same: when the tool becomes load-bearing, custom pays for itself within 18 months.

The honest summary

Pick the tool that matches the lifespan and the audience, not the one that has the best demo. Retool is excellent at being Retool. Lovable is excellent at exploring. A senior engineer is excellent at building something that lasts. Treat them as different shapes, not better and worse versions of the same thing, and the decision gets easy.

Frequently asked questions