In this article
Let's start with a sentence you wouldn't expect from a company that migrates clients off Retool: Retool is a good tool, and in most cases we are the ones advising against migration.
We're writing this after moving seven Retool apps onto Open Mercato at a company that makes custom orthoses. So we know both sides. This piece is about recognising the right moment — because the hard part of that decision isn't comparing features, it's honestly naming what has changed inside the company.
What Retool does better, and Open Mercato won't take away
Before we get to the ceiling, let's be clear about what people pay Retool for — and rightly so. A custom system gives you none of these three things for free.
- 1
You need no infrastructure
You create an account and an hour later you have a screen reading from your database. No hosting to set up, no deploys, no question of „who restarts this at 2 a.m.”. Open Mercato won't replace that — it's a system that has to run somewhere and somebody has to maintain it.
- 2
Dozens of ready-made connectors
Postgres, MySQL, S3, REST, Google Sheets — all wired up by clicking. In a custom system you configure each integration yourself, and every one of them is a piece of code someone will have to maintain.
- 3
The first screen in an hour, not a week
For an internal panel that shows data from a database and lets people fix it, there's hardly a better tool. Genuinely.
That's why the sentence we say to clients most often is: a year ago Retool was a good choice. That isn't politeness. The decision made a year ago was rational under the conditions of a year ago, and the fact that something better exists today doesn't invalidate it — it simply ends it. Migration is not an admission of error. It's the moment a tool has done its job.
Where the ceiling is
Retool's ceiling isn't in what it can't draw. It's in what it can't enforce. Retool displays and edits data brilliantly, but it isn't a system: it doesn't hold your domain rules, doesn't know your process, doesn't know who shouldn't see what. You have to build all of that yourself — separately in every app. And in time there are seven apps.
Here is what we found at the orthopaedic company after a year on Retool. None of these points is a charge against the tool — each is a symptom that the process outgrew the layer it was built in.
- One status described two different things. A record had a status from 1 to 12, mixing the life cycle of a patient consultation with the workshop production stage in the same list. „A consultation in state: thermoforming” is a sentence that means nothing — and you can build neither a report nor an automation on it.
- Medical data sat unencrypted. National ID numbers, medical histories, addresses, patient notes — all in plain text in the database. GDPR treats health data as a special category and requires encryption at rest. That isn't Retool's fault: it never promised per-field encryption. There simply is no place in low-code where such a layer would naturally sit.
- The technician could see everything. The workshop app displayed the national ID, address and medical history, even though the job needs only the specification and the measurements. Restricting visibility would have to be hand-written in every app separately — with no guarantee nobody bypasses it with a query on the side.
- There was no audit trail and no undo. Every status change and every assignment was irreversible and anonymous. You couldn't answer „who moved this and when” — a question that comes up daily in production planning.
- The form lost data. The multi-step consultation form could wipe itself on a page reload. The team learned to live with it — the worst possible symptom, because it means they stopped reporting it.
- Company knowledge lived in dropdowns. Orthosis types, materials, departments — hard-coded in the apps instead of living in dictionaries a non-technical person could manage. Every change to the offering meant a ticket to a developer.
- Planning escaped into Excel anyway. The coordinator scheduled the workshop in a spreadsheet, because the system had no way to do it. That's the clearest signal you'll get: when the company's most important process falls out of the system and into a spreadsheet, the system has stopped serving the company.
The crossover point — let's do the maths
Retool charges per head, at two rates. A builder is someone who edited an app in a given billing cycle; an internal user is someone who only uses it. The classification is dynamic — the same person can be one or the other from month to month. On the Business plan that's €46 per builder and €14 per user per month (in dollars, billed monthly: $65 and $18).
Retool Business, zespół 2 budujących + 20 korzystających: (2 × 46 €) + (20 × 14 €) = 372 € / miesiąc = 4 464 € / rok Kwota wraca co roku i rośnie z każdym zatrudnionym.
Two things in that calculation are easy to miss:
- The Business plan gives you the same number of workflow runs as Team — 5,000 a month. You're paying five times more for features and permissions, not for automation throughput.
- Self-hosting realistically starts at Enterprise. If the reason for the conversation is where the data physically sits, the cheaper plans are out from the start.
On the other side, the Open Mercato core is MIT-licensed — no per-user fees at all. You pay once for the implementation, then for hosting and optional support. But let's be honest to the end: the implementation isn't free and neither is maintenance. At twenty people the crossover point lands after a few years, not a few months. If someone shows you a chart where a custom system pays for itself in a quarter, they're showing you a sales pitch, not a calculation.
When to stay on Retool
Stay if you recognise at least three of these five:
- Your app is a layer over a database — show, fix, add. Retool does that faster and cheaper than anything else.
- A handful of people use it and that number isn't growing. The per-head model only hurts at scale.
- You have no sensitive data. Without national IDs, medical records and specially protected personal data, the heaviest argument for migrating disappears.
- The process is flat. One entity, one life cycle, no roles that must see different things.
- You have nobody to maintain it. A custom system needs someone accountable. If there's neither such a person nor a partner, Retool is the safer choice — and that's a serious argument, not an excuse.
If you recognise yourself in that list, migrating will make your situation worse. We tell clients this regularly, and it isn't a rhetorical device — it's the most common recommendation we give on this topic.
What the move looks like
Three things from our implementation worth knowing before you start.
- 1
Separate what had been glued together
One 1–12 status split into two independent cycles: the consultation's life on one side, the production stages on the other. The team's list still shows a single status column so nobody loses the view they're used to — but underneath there are now two processes you can ask about separately.
- 2
Not everything has to be migrated
We deliberately did not move the production process data. The process had been maintained unreliably in Retool: most cases were closed history already visible on the consultations, and the dozen or so orders in progress were recreated by hand on the new board in a single day. Moving rubbish into a new system costs more than retyping twenty records.
- 3
A parallel period
Retool doesn't disappear on go-live day — it stays read-only as an archive until the team stops looking at it. That costs one more month of subscription and saves a week of panic.
And the thing you only see afterwards: the most time went not into writing code, but into recognising the process. Discovery took longer than implementing the first three modules. Not because something went wrong — but because for a year in low-code nobody had to name that process. The tool let people click it without describing it, and that convenience comes back with interest at moving time.
What follows from this
Retool is an excellent tool for building panels and a poor one for running a company. That's not a charge — it never promised the latter. So the question to ask isn't „is Retool good”, it's: am I still building a panel, or am I already running the company on this? If the coordinator plans in Excel, the technician sees data they shouldn't, and nobody can say who moved a status — you already know the answer.
If you don't know the platform itself yet, start with the introduction to Open Mercato. And if you'd rather see an implementation in a less sensitive industry, we also wrote up a case study from a sewing workshop, where the starting point was six months in a low-code tool.
Retool prices checked on 29 July 2026 against the vendor's official pricing page. Low-code pricing changes often — verify at the source before deciding.
Mateusz Kozłowski
Founder of flowbiz · Process automation expert
I implement automations, integrations and AI in mid-sized companies across Pomerania and Kuyavia-Pomerania.
