ImportFlow

Embedded customer CSV importer for Supabase SaaS.

Visit Website
September 29, 2026 The CSV import was never the hard part

The migration pilot was useful for one thing: it made the bigger problem much clearer.

Getting one CSV into a database turned out to be the easy part. The actual problem is giving customers a way to bring their existing data into a SaaS product without turning every import into another support or engineering job.

I'm building ImportFlow as an embedded customer importer for Supabase SaaS. Customers bring CSV or spreadsheet data into the product, work through mapping and bad data there, and get a clear result instead of handing the file back and forth with the team.

I'm still building the first usable release, but I've opened early access while I do it. I want the first version shaped by teams that already deal with customer imports, not by a feature list I guessed at on my own.

If your customers bring data from another tool, I'd like to hear how you handle it today and what you wish the importer could take off your team's plate.

Early access: https://importflow.dev/#alpha

Comment

September 15, 2026 I built the checker first. Now I’m testing a $500 migration pilot

I’m testing whether a SaaS team will pay for migration preparation before I build the full importer. The problem is a customer onboarding that stalls because their data still needs to be mapped and prepared. I built an open-source PostgreSQL checker to work through a smaller question first: what does the destination table require from the source data? The current ImportFlow offer is a $500 fixed, founder-assisted pilot for one supported Supabase table, insert-only. I want to learn which preparation work is worth paying for before automating more of it.

A spreadsheet column and a database column can have the same name without meaning the same thing. An ID might belong to the database. A tenant value needs an authority decision. A declared unique constraint says nothing about whether the incoming values already exist.

PG Import Check takes migration SQL or DDL, including a supported base CREATE TABLE for the target, and lets you choose a discovered table. Its Decision Report and Import Contract organize source requirements, defaults, generated values and unknowns. The dated ImportFlow profile affects its decisions and mapping groups; a profile exclusion such as JSONB is not a PostgreSQL error.

It runs locally in the browser. No signup, database connection or SQL upload. You can use the complete report without ever talking to me:

https://check.importflow.dev

Building it made the gap between declarations and runtime behavior very concrete. A DEFAULT can provide a value when a column is omitted, but finding the expression doesn’t prove it will succeed. Finding an RLS policy doesn’t prove the import role has the intended access. The checker doesn’t validate CSV rows or execute imports, and unsupported migration changes remain explicit.

The paid pilot is deliberately manual. We agree a narrow scope for one supported writable public table, work with sanitized or synthetic data in disposable local staging, and prepare a handoff. The buyer’s engineer reviews and executes the final production COPY. Their production credentials stay with them. A hosted, self-serve importer isn’t available today.

I don’t yet know whether enough of this work repeats to justify a self-serve subscription product. The fixed pilot lets me test whether the preparation itself is valuable and see where the scope breaks. It is an offer under test, not evidence that people will buy it. I also need to avoid building myself an open-ended custom service.

I’m building this from Egypt while finishing secondary school. The offer and its limits are here: https://importflow.dev/design-partner

For founders who have handled customer migrations: on the last one, what consumed the engineering time after you had a readable file? I’m particularly interested in where a one-table preparation service would have been too narrow to help.

1 Comment

  1. 1

    The $500 pilot is a useful test because you’re validating the preparation work before automating the importer. The key signal seems to be whether the same preparation decisions recur across customers—do you already see a common subset of migration work, or does each pilot look materially different?

About

The private Alpha is still in development. I’m talking with SaaS teams that already handle customer imports and want to help shape what gets built first. Request Alpha access: https://importflow.dev/#alpha