Should I vibe code
Generate a small operational app from a table and a limited rules engine
Small operational apps are how shadow IT starts, and shadow IT is always someone’s Tuesday problem.
?
Their verdict, the Core price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Generating CRUD from a table is well within reach. Just be clear with yourself that an operational app becomes load-bearing faster than you expect.
What actually breaks
not "if". the specific failures.
- Offline, which operational apps need by definition — the warehouse, the van, the basement — and which is a sync engine, not a cache
- Conflict resolution, once two field staff edit the same record from two phones with no signal between them
- The rules engine, which starts as three conditions and becomes a language once someone needs 'unless'
- Photo capture and upload, which is the single most requested feature in operational apps and the least reliable on bad connections
- The person who owns it leaving, taking the only understanding of the rules with them
Two technicians update the same job record while out of signal — one marks it complete, one adds parts used. Both phones sync when they get back to the depot. Your write is last-one-wins on the whole record, so the parts vanish under the completion, or the completion vanishes under the parts. The database is perfectly consistent. The job is billed wrong, and nobody will notice until the customer queries the invoice, by which point neither technician remembers what they typed.
Is that you?
the verdict is a default, not a law
- It is always online, on desks, with a reliable connection
- One person edits a given record and concurrency is genuinely not a question
- It is a form that appends rows rather than an app that edits them
- Field staff use it away from reliable connectivity
- Two people can edit the same record
- Records hold personal data about customers or staff
- You are the only person who understands the rules and there is no documentation
If you build it anyway
the checklist, then the prompt that enforces it
- Decide about offline before the schema. Retrofitting sync onto an online-only app is a rewrite, and operational apps almost always need it.
- If offline is in scope, sync field-level changes rather than whole records, so two people editing different fields both survive.
- Give every record a version and detect conflicts explicitly. Silent last-write-wins is how billing goes wrong quietly.
- Queue photo uploads separately from record writes, with retry, so a failed image does not block a completed job.
- Write the rules down in plain language next to the code. The bus factor on internal operational tools is routinely one.
- Append-only where you can: a log of events is far easier to reconcile than a mutable row.
Before you build an operational app from a table, apply these and push back if I ask you to break them. 1. Ask me where this is used. If any answer involves a vehicle, a warehouse, a basement or a customer site, tell me offline is a requirement rather than a nice-to-have, and that it must be designed in before the schema. 2. If offline is in scope, sync changes at field level, not whole records. Explain that last-write-wins on a whole record silently discards a colleague's edit to a different field, and that this shows up as a billing error weeks later. 3. Give every record a version or vector, detect conflicts, and surface them to a human rather than resolving silently. 4. Prefer an append-only event log over mutable rows wherever the workflow allows. Reconciling a log is tractable; reconciling two versions of a row is guesswork. 5. Queue photo and file uploads independently of record writes, with retry and visible status. A failed upload must not block a completed job. 6. Keep the rules engine small and explicit. Write each rule in plain English as a comment beside its implementation, and tell me the bus factor on this tool will be one. 7. If the data includes customer or staff personal information, ask me who may see what and enforce it on the server. 8. Out of scope unless I ask: barcode scanning, signatures, geofencing, printing. 9. Tell me what happens to a day's work if a phone is lost before it syncs.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If the app goes into the field, buy it. $10 a month per user is cheap against an offline sync engine with conflict handling, which is the actual difference between the demo on your desk and a tool a technician can rely on in a basement.
$10/mo is cheaper than your weekend.
Keep the underlying table exportable and the rules documented in prose, because the rules are the part that lives only in one person's head. If the tool is abandoned, the data should be readable as a plain table without needing to know what your conditions meant.
Large open-source low-code platform for internal applications and data sources.
Questions
Can't I just sync when the connection comes back?
That is the easy half. The hard half is what to do when two devices reconnect with different versions of the same record. Sending both up is simple; deciding which parts of each to keep is the sync engine — and the naive answer, whole-record last-write-wins, quietly deletes work that was done correctly.
Why does field-level sync help so much?
Because most real conflicts are not conflicts at all — one person edited status, another edited parts. Merging at field level lets both survive without asking anyone. You only need human resolution when two people genuinely changed the same field, which is rare enough to be manageable.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Generating maintainable mobile code from a schema is the thing every team has tried and abandoned.
An internal tool is just a production database with a friendlier delete button.
Telegram bots are the easiest backend you will ever ship, which is also the warning.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice