Retool vs Laravel for a 3-week ops dashboard: a scoring method

It is a Tuesday in May at a logistics operator off the A16 in Dordrecht. Twenty-six people, twelve trucks, four trailer types, a dispatcher with two screens and a phone wedged between her shoulder and her ear. The order intake lives in an Excel file shared over a Synology. The trailer status lives in WhatsApp. The fuel card spend lives in an email folder. The auditor visits in six weeks for an ISO 9001 surveillance audit, and the new compliance officer has just realised there is no defensible record of who changed what.

The CEO calls us on a Thursday. He needs an ops dashboard in three weeks. He has heard of Retool. His nephew, who codes a bit, has heard of Laravel. He wants to know which one we would pick if we were him.

This is the method we use.

The three scores that actually matter

Every internal-tools decision turns the same three knobs. Time to first usable screen is the loud one, but it is the least durable. The three that decide year two are:

1. Data-model churn. How often will the underlying schema move in the next eighteen months?
2. Year-two maintainer. Who keeps it running thirteen months from now, after the launch sugar wears off?
3. Audit trail. What evidence will an external auditor actually accept?

Score each one from 1 to 5 for both options. Total out of 15. Highest wins. Tie goes to the option whose failure mode is cheaper to undo.

Score one: data-model churn over eighteen months

Retool builds queries that reference column names directly. Every screen, every filter, every export holds a soft pointer to a table shape. Rename trailer_id to asset_id and you do not get a compile error, you get a Tuesday spent finding the seven places it broke.

A hand-built Laravel admin (we use Filament for most of these) routes the schema through Eloquent models. Rename the column, run a migration, and the app fails loudly at boot. Loud failure is cheap. Silent failure costs you the auditor's trust.

The score:

• Schema you expect to freeze inside the first month: Retool 5, Laravel 4.
• Schema you know will move quarterly: Retool 2, Laravel 5.
• Schema you cannot predict because the process itself is being designed: Retool 1, Laravel 5.

The Dordrecht brief lands in bucket three. The compliance officer is still drafting the trailer-handover process. The dispatcher wants a status field but cannot yet name the states.

Score two: the person who owns it in month thirteen

Internal tools die in year two, not year one. The launch team moves on. The original Notion doc rots. Someone is left with the tool and a Slack channel of small requests that never quite close.

Retool's pitch is that the year-two owner can be an ops lead with a SQL habit. That is true when the change is "add a column to this table, add it to this screen." It is not true when the change is "we now bill per pallet, not per trip, restructure the invoice flow." For the second kind, you need the same skills you would have needed to build it in Laravel, plus knowledge of Retool's quirks. The skill ceiling does not vanish; it relocates.

Ask the client one question: is there a named human who will own this tool in month thirteen, and what is their day job?

• In-house developer or technical co-founder: Laravel 5, Retool 3.
• Operations lead who writes SQL for fun: Retool 4, Laravel 2.
• Nobody named yet: Laravel 4, Retool 2. (You will end up maintaining it. Pick the stack you can hand to a freelancer in 2028.)

The Dordrecht CEO names his planner. She runs queries in MySQL Workbench and writes Excel macros on the weekend. She scores a 4 on the Retool side, a 2 on Laravel.

Score three: the audit trail an auditor will actually accept

This is where most internal-tools posts wave their hands. Auditors do not want "we log everything to the database." They want an append-only record they cannot quietly edit, tied to an authenticated identity, with a timestamp the auditor trusts.

For ISO 9001 in a Dutch logistics context, that usually means: who changed the trailer state, when, from what to what, and what document supports the change. The auditor will sample twenty rows. If any of them cannot be reconstructed, the finding goes in the report and the certificate goes on a watch list.

Retool's built-in audit log (on the Team plan and above, see the Retool audit log docs) records who ran which query. It does not, by default, record the before-and-after values of the row that query touched. You can wire that up with a Supabase trigger writing to a separate audit_events table, and we do, but the auditor will then ask who can delete from audit_events. With Supabase service-role keys floating around in Retool resources, "anyone with Retool admin" is the honest answer.

A Laravel build with a proper audit table (we lean on owen-it/laravel-auditing for the boring 80%) lets you put the audit writes behind an interface the application cannot bypass, then put the table itself behind a Postgres role the application user does not own. The auditor reads that as tamper-resistant. Retool reads as tamper-evident, with effort.

Both options sit on Postgres in our world, so the difference is not the database. It is what each layer above the database lets you actually guarantee in writing.

The score:

• Light audit need, internal use, no certification: Retool 4, Laravel 4.
• ISO 9001, AEO, or a similar surveillance audit: Retool 2, Laravel 5.
• Regulated finance, healthcare, or anything where a finding costs a licence: Retool 1, Laravel 5.

Running the scores against the Dordrecht brief

Three weeks. Greenfield process. SQL-fluent planner. ISO 9001 surveillance.

                       Retool + Supabase   Laravel + Filament
Data-model churn               1                   5
Year-two maintainer            4                   2
Audit trail                    2                   5
-----------------------------------------------------------
Total                          7                  12

Laravel wins twelve to seven. The three-week deadline is the part the CEO will push back on, and he is right to. So we split the brief.

Week one: model the entities with the planner on a whiteboard, agree the states, write the migration. No screens yet. Week two: build the four screens the dispatcher uses every hour in Filament, wire the audit table, seed it from the Excel. Week three: usability rounds with the dispatcher and one driver, deploy to a small VPS, hand the planner a runbook.

The screens she does not use every hour (fuel reconciliation, monthly KPI export, customer-facing PDFs) get a second sprint after the audit. We do not need them on day twenty-one. Saying that out loud to the CEO on day one is the part that buys you the schedule.

The case where Retool wins

The same method points the other direction for a different brief. A marketing agency we worked with last year needed a campaign-tracking dashboard. Schema was stable (campaigns, channels, spends, results). The year-two owner was the head of paid media, who lived in SQL. There was no external audit. Retool scored 13, a Laravel build scored 9. We shipped Retool in nine days and the agency has changed almost nothing since.

The method is not "Laravel always wins for ops, Retool always wins for marketing." It is "score the three knobs honestly, and let the numbers fall." The boring stack often wins the boring problem, and that is fine. The interesting work is upstream, in the question of what the tool should remember.

The smallest thing you can do today

Open a blank page. Write the names of the five entities your ops team argues about most. Next to each, write whether you can list its states. Next to each state, write who is allowed to move it forward and backward. If you cannot finish that sheet in an hour, no tool will save you. If you can, the choice between Retool and a hand-built admin is now a real conversation, not a vendor pitch.

When we built the ops dashboard for the Dordrecht client, the thing we ran into was that the dispatcher's "status" field actually encoded three different things at once: trailer location, paperwork state, and driver availability. We ended up splitting it into three columns before writing a line of Laravel, and the audit table got a lot easier to defend. If you want help running the same scoring against your own backlog, that is the kind of process automation work we do.