Should I vibe code
Build one internal CRUD tool over a trusted database with role-aware actions
An internal tool is just a production database with a friendlier delete button.
?
Their verdict, the Team 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
One CRUD screen over a trusted database is a genuinely good use of an afternoon. It is also unaudited write access to production, handed to whoever has the link, with no undo.
What actually breaks
not "if". the specific failures.
- A DELETE without a WHERE clause, run against production, by someone who was helping
- An unbounded query that locks a table during business hours
- Access control that is really just an unguessable URL
- A form that writes a bad value into a column nothing validates
Someone in ops was clearing test accounts using the little admin panel you built in an afternoon. The filter box was empty, which the panel interpreted as "match everything", and the delete button did not ask twice. There is no audit log, because it was only ever meant to be an internal tool, so the first task is working out what used to be there.
Is that you?
the verdict is a default, not a law
- It is read-only
- It operates on a replica, not the primary
- Every write is scoped to a single record and confirmed
- It can perform bulk writes or deletes
- Access is controlled by URL obscurity rather than authentication
- There is no audit trail of who changed what
If you build it anyway
the checklist, then the prompt that enforces it
- Start read-only. Add writes one operation at a time, each with an explicit confirmation.
- No bulk destructive operations. If a bulk delete is genuinely required, make it a soft delete.
- Real authentication, plus a role check on the server for every action — never only in the UI.
- Audit log every write with actor, timestamp, before and after. Non-negotiable for anything touching production.
- Use a database role with only the permissions the tool actually needs, not the application superuser.
- Parameterised queries only, and cap every result set.
I am building an internal admin tool over a production database. Treat production as sacred: 1. Version one is read-only. Do not write any mutation code until I explicitly ask, and when I do, add one operation at a time. 2. Connect using a dedicated database role with the minimum grants required. Show me the exact GRANT statements. Never use the application's main credentials. 3. Every mutation is scoped to a single primary key. If I ask for a bulk operation, implement it as a soft delete (deleted_at) and tell me why. 4. Every write goes through an audit table in the same transaction: actor, timestamp, table, row id, before JSON, after JSON. If the audit insert fails, the write fails. 5. Authentication is server-side and checked on every request handler. Hiding a button in the UI is not access control — do not treat it as such. 6. All queries are parameterised and every SELECT has a LIMIT. No string interpolation into SQL anywhere, no exceptions. 7. Destructive actions require typing the record identifier to confirm, not just clicking OK. 8. Add a read-only 'safe mode' env flag that disables all mutations, and make it the default so production has to be opted into. 9. Write a README section: which tables this can touch, which operations exist, and how to revoke access in a hurry.
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
Once more than two people use it, or once it touches customer data, the audit logging, permissions and SSO you would have to build are exactly what the $15 a month is for.
$15/mo is cheaper than your weekend.
Because the tool is a thin layer over the database, retiring it means revoking one database role. Keep it that way: the moment the tool holds state of its own, it stops being disposable.
Large open-source low-code platform for internal applications and data sources.
Questions
It is only used by three people I trust. Does that not change it?
Trust is not the failure mode. Interface design is. The delete button that does not ask twice will eventually be clicked by someone who was going quickly, and the absence of an audit log is what turns a mistake into an investigation.
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.
Telegram bots are the easiest backend you will ever ship, which is also the warning.
A no-code platform is a programming language with a GUI. You are writing a compiler.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice