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:
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.
@aryan_sinh I’ve been trying to reply to your comment for about 20 minutes, but the reply/comment buttons on the ImportFlow product post seem broken for me, so I’m answering here instead.
That’s exactly what I’m trying to learn. I don’t have enough real pilots yet to say there’s a repeatable pattern, but my hypothesis is that source-to-target mapping, database-owned values, defaults, tenant authority, and constraint review will repeat more than the customer-specific data itself.
The one-table scope is partly to make that easier to observe. If every migration still turns into a completely different service job, that would be an important signal too.
In your experience, which part of migration work tends to repeat the most?
The repeatability question is exactly what I’d be interested in digging into. Since the post replies are being flaky for you, what’s the best email to reach you on?
Sure mohamed@importflow.dev .
Happy to continue the conversation there
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.