Should I vibe code
Build a small table-based operational tracker with views and API columns
Every column is an API key plus a cron. That is not a database, it is a credential store that dials out.
?
Their verdict, the Economy price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
The other spreadsheet-databases on this site store rows. Stackby's defining feature stores keys. Its columns are API calls — you paste an Ahrefs, SEMrush, Clearbit, Hunter, Twilio or OpenAI credential into the base and the column fills itself, or in the vendor's own words, you "link your columns to APIs to pull information, use services or push information". Rebuild that and you have not built a database, you have built three things wearing a grid: a credential store, a scheduled outbound HTTP client, and a billing surface. The credential half fails in the most familiar way there is, with the keys landing in a settings table next to the rows and being rendered straight back into the config modal so anyone with base access can copy them. The billing half is the one you meet first, because recalculating a column across five thousand rows is five thousand metered calls and nothing in the obvious implementation says no. And the push half is the one you cannot take back, because a fill-down on a column wired to Twilio is a broadcast to real phone numbers, triggered by a drag.
What actually breaks
not "if". the specific failures.
- The keys, which end up in the same database as the rows, readable by everyone with access to the base, and echoed back into the settings form so they can be copied out
- Rate limits. The refresh loop does not know what one is until the shared company account at the other end is throttled or suspended, and it is never your personal key that gets suspended
- The bill. Five thousand rows of enrichment lookups is five thousand billable calls, it arrives a month later, and it belongs to whoever's key was in the column
- Push connectors, which turn a fill-down into a mail merge with no preview and no draft state
- Stale cells that look live. The column shows a number fetched in March and nothing on screen says which March
- Coupling to somebody else's schema — a field renamed upstream turns the column into nulls across every row at once, quietly, and the rows that used it in a formula follow
- Retries against a non-idempotent endpoint, so one timeout at the network layer becomes two messages at the recipient
Someone wants to text the forty customers whose renewal falls this week, and the base already has a column wired to Twilio, because that is what the column type is for. They filter, type the message into the first cell, grab the corner and drag. The filter was on a formula field that had not recalculated since the last refresh, so the selection is not forty rows, it is eleven hundred — active, churned and duplicated records alike. The template interpolates a first-name field that is empty for most of them, so most of the eleven hundred get a message beginning "Hi ,". There is no draft state, because a cell either has a value or it does not. There is no outbox, because the connector fires on write. There is no undo, because Twilio delivered the lot inside a minute. On Monday you learn that ninety of those numbers were on a suppression list that lives in a different tool, and that the API key belonged to the account the support team also uses.
Is that you?
the verdict is a default, not a law
- The base is yours alone, and so is every key in it
- Every connector is read-only and pulls something public — a view count, a rank, an exchange rate
- Refresh is manual and bounded, and you would notice the invoice
- Nothing in it can send, post or write to another system
- A team shares the base, which means the team shares the keys
- Any connector can send a message, publish a post or write to a third-party system
- The credentials belong to the company rather than to you personally
- A schedule refreshes metered columns while nobody is watching the spend
- The rows are customer contact details, because then the sending column is one product decision away
If you build it anyway
the checklist, then the prompt that enforces it
- Keys never live in the same store as the rows. Put them in a secrets manager or the environment, reference them by name, and make the settings UI write-only — once entered, a credential is never rendered back.
- One key per connector, scoped as narrowly as the vendor allows, and read-only wherever a read-only token exists.
- Give every connector a per-run call ceiling and a monthly budget. Exceeding it stops the run and tells somebody; it does not silently truncate.
- Show a fetched-at timestamp in the cell. A cached value with no age on it is a wrong answer waiting for a meeting.
- Do not build a connector that sends. If you eventually must, it goes through an outbox with a rendered preview, a row count, and a delay long enough to cancel.
- Back off on 429 with jitter, and attach an idempotency key to anything that is not a GET, so a retry cannot deliver twice.
- Log every outbound call with row, connector, timestamp and cost estimate. This is the only way you will ever reconstruct what a refresh actually did.
- Rotate every key the day the project stops being interesting, because an abandoned side project holding live credentials is the worst object in your account.
I am building a spreadsheet-database where some columns fetch their values from
third-party APIs using keys I supply. Treat it as a credential store that makes
outbound calls and spends money, because that is what it is. Push back when I
ask to loosen any of this.
1. Design credential storage before the grid. Keys live in a secrets store,
referenced by name — never a column, never a row, never in any response.
2. The settings UI is write-only for secrets. Show a masked fingerprint and a
last-used date; never render a stored key back into a form field.
3. Phase one connectors are GET-only against public data. Do not implement a
connector that writes, sends or posts until everything else is finished.
4. Every connector declares a per-run call ceiling and a monthly budget in
config. Exceeding either aborts the run with an error I can see. Never
truncate silently.
5. Log every outbound call: row id, connector, timestamp, HTTP status and an
estimated cost. I need to be able to answer "what did that refresh do".
6. Cache values with an explicit fetched_at, surface the age in the cell, and
never let a stale value be indistinguishable from a fresh one.
7. Implement backoff with jitter on 429 and 5xx, and a circuit breaker per
connector. A tight retry loop against a shared company account gets that
account suspended, not mine.
8. Any non-GET call carries an idempotency key. A network timeout must not be
able to deliver a message twice.
9. If I ask for a sending connector — SMS, WhatsApp, Slack, email — build an
outbox instead: staged rows, a rendered preview of the first ten, the total
count, and a cancellable delay before dispatch. Fill-down must not send.
10. Provide a key-rotation command and put it in the README next to a line
saying to run it when the project is abandoned.
11. Out of scope, and say so plainly: OAuth flows for every vendor, per-user
credentials, and a connector marketplace. If I need those, n8n already
solved them and Stackby is $9 a seat.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
As soon as more than one person needs the base. $9 a seat a month — nearer $4 if you pay annually — buys credential handling you did not write, rate limiting and retry semantics for dozens of APIs, and someone else's problem when a vendor changes a response shape. The argument gets stronger, not weaker, the more connectors you want: each one you add to a homemade version is another auth scheme, another quota model and another way to spend money by accident.
$9/mo is cheaper than your weekend.
The rows export cleanly; the connectors do not. What leaves with a CSV is a snapshot — every API column becomes whatever number it happened to hold, with no way for the next tool to know how it was derived or when. So write down, per connector, which vendor and which endpoint produced the column, and export with the fetched-at timestamps rather than just the values. Then do the part everyone forgets: revoke and rotate every key the app ever held. An abandoned project with live credentials in it is worse than no project, because nobody is watching the bill or the audit log any more.
Open-source no-code database with roles, shared views and an audit log already in place.
Fair-code workflow tool whose credential storage, rate limiting and retry handling across hundreds of APIs is exactly the layer an API-column feature reinvents.
Questions
Is this really different from rebuilding Airtable?
Yes, on one axis that matters. Airtable's failure mode is losing or corrupting rows you own. Stackby's headline feature means the base also holds live credentials for other systems and makes calls with them on a schedule, which adds two things a plain grid never has: a secret worth stealing and an action with consequences outside your database. The grid part of the work is the same. The rest is not.
What will an agent get wrong first?
Credential handling, and it will look reasonable. Keys get stored in the application database because that is where configuration lives, and the settings page reads them back so the field is not blank when you return to it. Both decisions are the natural implementation and together they mean anyone with access to the base — or to one SQL injection, or to a backup — has your Twilio account.
What is the safe version?
Read-only connectors against public data, refreshed manually, with a call ceiling and a visible fetched-at. That keeps everything genuinely useful about the idea — a table that enriches itself — and removes the sending, the runaway schedule and most of the bill. If a connector needs to write somewhere, that is not a column any more; it is an integration, and it belongs behind a preview and a confirmation.
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.
An agent will happily hand you a spreadsheet with UPDATE on production. Postgres has no undo button.
A spreadsheet with types is easy. A spreadsheet with types that a team edits at once is not.
User-editable formulas are user-supplied code. eval() in a shared doc is RCE with a grid on top.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice