Turn a Google Sheet into a database, without trusting a robot's guesses

Matt Bidwell · 12 August 2026 · 4 min read

Every business has a spreadsheet that stopped being a spreadsheet a while ago. Forty columns, three people editing it, a tab called "OLD DO NOT USE". It wants to be a database. The only question is how much of your data survives the trip.

The tools that convert spreadsheets into apps mostly share one design choice: they guess. They read your columns, decide what type everything is, build the thing, and show you the result. It's a great demo. The problem is what a wrong guess looks like afterward: nothing. The import reports success, the row count matches, and the damage is quietly distributed through your data where you'll find it one record at a time, for months.

The date that ruins your quarter

My favorite example, because it bit a customer migration I did by hand: a column full of dates like 03/04/2026. That's the 3rd of April in Britain and March 4th in America, and a CSV export doesn't say which. A guessing importer picks one, gets most rows "right" by coincidence, and now a third of your follow-up dates are wrong in a way that looks exactly like being right. There's no error to catch, because nothing errored.

Dropdowns have the same failure shape. If a Status column holds Active, On hold, and Closed, it should become a dropdown with those three choices. But a tool that silently invents the option list will happily add "Actve" as a fourth status because row 214 had a typo, and every view that groups by status inherits the mess.

What review-first looks like

When I built the Google Sheets importer for Bionic Forms, the rule was: every guess gets shown with its evidence, and where a wrong guess would be silent, the importer asks instead of deciding. The flow:

1. Paste the sheet's link. If it's shared "anyone with the link", that's all you need. No upload, no export, no connecting your Google account.
2. Read the proposal. One row per column: the field type it chose, why ("every value matched an email address", "a small set of values repeats, so this is a dropdown"), and sample values from your actual data so you can check the claim.
3. Answer the questions it refused to guess. Ambiguous dates get a day-first or month-first question. That's the whole interruption.
4. Import. Columns become typed fields, rows become records, and the collection gets a table view. If any value can't be read, nothing imports — you'll never get a half-loaded collection where you can't tell which rows made it.

All or nothing sounds harsh until you've re-run a partial import and doubled four hundred records. A migration you can trust is one that either happened or didn't.

Why a database instead of the sheet

The sheet was fine until it had to be three things at once: the place data lives, the form people fill in, and the report your boss reads. A database app splits those honestly. Fields have types, so a phone number can't wander into the date column. Records have history, so you can see who changed what. Views are separate from data, so reorganizing a screen doesn't reorganize the truth. And a public form can feed new records in from outside without handing anyone the whole spreadsheet.

Bionic Forms is early (I publish the numbers: 12 users, none paying yet), and the paste-a-link import shipped this week. It works today in the browser, and everything it builds syncs to the desktop app, which keeps working offline. A live OAuth connection that picks sheets straight from Drive and keeps them in sync is built and headed into Google's verification process — the paste-a-link path stays either way, because needing zero permissions is a feature.