Built in the open · no self-serve, no sales team, one founder
Your customer’s spreadsheet should never be able to write a tenant_id.
Every CSV a customer sends you is untrusted input pointed at production. ImportFlow reads your actual Postgres catalog and tells you what that file can safely fill in — and which columns it must never touch. Derived from your schema. Not re-typed into someone’s dashboard.
No signup. No database connection. Paste a table definition.
01excel silently turned 3 product codes into dates
02"Active", "active", "ACTIVE" — your enum accepts exactly one
03the file has an account_id column. so does your table. they must never meet
04the insert fires a trigger. the trigger sends email. there are 4,000 rows
05job died at row 2,000 — which of rows 1–1,999 actually landed?
──none of this is exotic. it’s tuesday.
Built for one specific situation
This is for you if:
- You run a B2B SaaS product with Supabase in production
- A customer needs to bring existing data in — probably soon, probably with a deadline
- One table carries most of the value (contacts, members, employees, products, users)
- You'd rather not hand anyone a key that bypasses your RLS
This is not for you if:
- You need multi-table or relational migration (not supported, not planned for launch)
- You need to update or upsert existing records (insert-only by design)
- Your destination isn't Supabase (other destinations are on the long-term roadmap)
- You need SOC 2, a DPA at enterprise scale, or an SLA (none of these exist yet)
I’d rather tell you it’s a bad fit now than three weeks in.
No signup. No database connection. Paste a table definition.
zero-trust, literally
The architecture assumes you shouldn’t trust me. Because you shouldn’t.
No service_role key. Ever.
Your Supabase secret key maps to service_role, which bypasses RLS entirely. Whoever holds it owns your database, and their breach becomes your incident. The architecture decision record for this project rejected that model on the record — it would have shipped months faster. Still no.
The check reads text, not your database.
You paste a CREATE TABLE. No connection string, no OAuth grant, no “read-only” key that turns out to be service_role. Nothing leaves your control, because nothing is requested.
Your schema is the spec.
Re-typing your columns into a vendor dashboard gives you a second schema, and second schemas drift. The import path here is derived from your live catalog — constraints, enums, triggers, generated columns, and the fields that must come from the session, never from the file.
Refusal is a feature.
A table shape I can't handle safely gets a refusal with a stated reason — not a best-effort guess that detonates at row 2,000. Every milestone behind this ships through independent adversarial review, findings against my own work included. Want to read them? Ask.
What’s actually built (a shorter list than the vision)
Schema fingerprinting. Catalog analysis. A contract compiler that emits a reviewable, deliberately non-executable description of a proposed import. The part that generates SQL lives behind a review gate and stays off until it passes — that’s the point, not a delay. No widget, no self-serve, no automated writes. If this page ever claims more than the repo proves, call me on it. Today, an import is the two of us: my analysis, your authority, your environment.
No signup. No database connection. Paste a table definition.
Straight answers
FAQ
Can't I just paste my schema into Claude?
Do — genuinely. A frontier model gives you a decent first pass, and you should use every free tool you have. What it won't do: run the full failure-mode checklist unprompted, refuse a table shape it can't handle instead of best-effort guessing, give you the same answer twice, or take responsibility for the import that follows. The analysis is the commodity. The accountable, reviewed write path is the product — and a chat transcript can't ship that.
Do you need my service_role key?
No. That key bypasses RLS, and the architecture for this project explicitly rejected the model where a vendor holds one.
Do you need access to my database?
Not for the compatibility check — that's a table definition you paste, nothing more. For an engagement, the import runs under your authority in your environment. I don't hold a standing credential.
Where are you based?
Egypt. I issue a manual PDF invoice, and you pay by bank/wire transfer through Nsave using the verified details on the invoice. There is no automated payment page. Any required tax treatment is confirmed by the parties professional advisers.
What happens to my data?
For the compatibility check: your table definition is processed to produce the report. For an engagement: we agree in writing beforehand exactly what I touch and what I retain, and it's sanitized data until there's a signed agreement covering anything else.
Is this a product I can sign up for?
Not yet. Today it's founder-assisted — I do the work with you. Self-serve is planned and not built.
Why is it insert-only?
Because updates and upserts require an identity model I can't yet guarantee is safe on someone else's production data. Inserting is something I can reason about completely. Updating isn't, yet.
What if my table isn't supported?
The check tells you, with the reason. Supported shapes are one writable table in public, with a primary key, accepting insert-only writes. Arrays, JSON columns, composite types, required foreign keys, views, and partitioned tables aren't supported.
Can it handle Excel?
CSV and XLSX are the target formats. Legacy .xls is not supported.
How is this different from CSVBox or Dromo?
Those are mature, shipping products with real compliance certifications, and if you need something today you should look at them seriously. The structural difference is that embedded importers validate a file and hand the data back for you to write. ImportFlow is being built to take responsibility for the write itself — safely, generated from your schema. That's a harder problem and it's why this isn't finished yet.
Who are you?
A solo technical founder. I'm building this in the open, with the architecture decisions and independent reviews recorded. Happy to send them.
Send your table. Get the analysis.
Paste your CREATE TABLE below — sanitized is fine. Within 24 hours you get back: which columns a customer file can safely fill, which are tenant- or session-bound and must never come from the file, and which constraints, enums, and triggers will bite you mid-import. No credentials, no connection, no signup. It's me doing the analysis for now, and that's a feature.
I use your email and submission only for the option you selected. Don’t include customer rows, passwords, API keys, or connection strings. Read the privacy notice.