Should I vibe code
No-code app builder for portals, dashboards, and mobile-style apps
A spreadsheet-backed app is a lovely afternoon and a permanent support obligation.
?
Their verdict, the Maker 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
Turning a table into a mobile-ish portal is genuinely easy now. The trap is that colleagues start relying on it, and then it is production software with no owner.
What actually breaks
not "if". the specific failures.
- Row-level security, because a spreadsheet has no permission model and filtering in the client is not a permission model either
- The API key or service account in the app, which grants access to the whole sheet regardless of what the UI shows
- Spreadsheet quotas and latency, which make a data source that was never meant to be a database feel like one
- Concurrent edits, where two users writing rows produce interleaving a sheet has no way to resolve
- Schema drift, when someone inserts a column in the spreadsheet and every index-based reference shifts by one
The portal shows each contractor only their own jobs, and it looks right, because the filter runs after the fetch. Someone curious opens the network tab and finds the response that populated the page: every row, every contractor, rates included. Nothing was hacked. The app fetched the sheet, as designed, and hid most of it in the browser — which is the default shape of every spreadsheet-backed app and is indistinguishable from a working one until somebody looks.
Is that you?
the verdict is a default, not a law
- Every user is allowed to see every row, and you have checked that sentence carefully
- It is read-only over data that is already public or already shared with everyone
- It is internal to a handful of people who all have the spreadsheet anyway
- Different users must see different rows
- The sheet holds personal data, rates, or anything one user should not see about another
- Filtering happens after the data reaches the browser
- Credentials for the whole sheet are shipped to the client
If you build it anyway
the checklist, then the prompt that enforces it
- Filter on the server, always. If the client receives a row it should not display, you have a disclosure rather than a UI bug.
- Never ship a sheet credential to the browser. All access goes through your own endpoint that applies the user's identity first.
- If per-user visibility is required, move the data into an actual database with row-level security. A spreadsheet cannot express this.
- Reference columns by header name, never by index, so inserting a column does not silently repoint every field.
- Treat the sheet as a single-writer store: write through one server-side path so concurrent updates serialise.
- Check the quota and latency numbers before designing around them — a sheet is not a database and gets slower in ways a database does not.
Before you build an app on top of a spreadsheet, apply these and push back if I ask you to break them. 1. Ask me the decisive question first: does every user see every row? If the answer is no, tell me a spreadsheet cannot express row-level security and that I should use a real database. Do not proceed to build per-user filtering on top of a sheet. 2. Never put a sheet API key, service account or OAuth token in client-side code. All access goes through a server endpoint that authenticates the user before fetching anything. 3. Filter rows on the server, before the response is sent. Explain that filtering in the browser means the data was already delivered, and that this is a disclosure, not a display choice. 4. Reference columns by header name rather than position. Someone will insert a column in the sheet, and index-based access will silently read the wrong field. 5. Route all writes through a single server-side path so concurrent updates serialise. A spreadsheet has no transaction and no conflict resolution. 6. Look up the current API quota and per-request latency for the sheet provider and tell me the numbers before I design around them. 7. Validate and coerce every value read from the sheet. Cells are strings and humans type into them. 8. If the data includes anything personal, say so explicitly and ask me who is allowed to see what before writing a line of UI. 9. Out of scope unless I ask: offline support, file uploads, push notifications.
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 you need per-user visibility, buy it or use a database — $60 a month is steep, but the thing you are paying for is exactly the row-level security a spreadsheet cannot provide. For a genuinely shared, everyone-sees-everything internal tool, building it yourself is reasonable.
Keep the sheet as the source of truth only while every user may see everything; the moment that stops being true, the exit is a real database and it is easier done early. Export to CSV with header names intact so the move is an import rather than a remodelling.
Open-source no-code database; combine with a frontend for many Glide-like apps.
Questions
Everyone builds spreadsheet apps this way. Is client-side filtering really a problem?
It is only a problem when rows differ in who may see them — which is most business apps and almost every portal. If the sheet is genuinely shared with everyone anyway, filtering in the browser is just a view. The danger is that the two cases look identical while you are building.
Why does referencing columns by index matter?
Because spreadsheets are edited by people, and inserting a column is a normal thing to do. Index-based references then read the wrong field silently — no error, just wrong data in the app — and the person who inserted the column has no reason to connect the two events.
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.
A no-code platform is a programming language with a GUI. You are writing a compiler.
Retries are the feature. A loop without them silently drops work; a loop with them sends it twice.
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