Add CSV Import to Your SaaS Without Building the Whole Workflow

Adding “Upload CSV” to a SaaS product sounds like a small feature.

It usually starts small too.

You parse a file, read the headers, turn the rows into objects, and send them to your API. Then a real customer uploads a spreadsheet with different column names, malformed email addresses, duplicate rows, blank values, Excel dates, or a header row you did not expect.

Now you are maintaining a data-import product inside your actual product.

Bootstrapware Importer is for the point where CSV import is easy enough to build, but annoying enough that you probably should not own it.

It gives your customers a complete import flow:

Upload CSV, XLSX, or TSV (including semicolon and pipe exports).
Pick an Excel sheet when the workbook has more than one.
Match spreadsheet columns to fields (with aliases for messy CRM headers).
Validate required values, types, locales, and uniqueness.
Preview rows and highlight problems.
Fix mapping or validation issues.
Return normalized JavaScript objects to your app.

Your application decides what happens next.

Bootstrapware does not receive the spreadsheet contents.

The simple version is not the expensive part

An AI coding agent can generate a CSV parser in minutes.

That is not the hard part.

The work starts when customers expect the feature to behave like a production feature instead of a demo:

Email Address needs to map to email.
Given Name, First, and First Name may all mean the same field.
A required field may be missing entirely.
Dates arrive in multiple formats.
Numeric cells are sometimes stored as text.
One bad row should not make the entire import mysterious.
Customers need to know what failed and why.
Duplicate rows need predictable handling.
Excel needs to behave like Excel, not like an afterthought.

You can absolutely build all of that yourself.

The question is whether spreadsheet importing is one of the things you want to keep maintaining.

What the integration looks like

A production integration is intentionally boring:

<Importer
  importerId="imp_customers"
  publishableKey="bsw_live_pub_..."
  onComplete={(rows, meta) => {
    // Send normalized rows to your own backend.
  }}
/>

Your importer configuration defines the fields your application expects. Bootstrapware handles the user-facing workflow around getting a messy spreadsheet into that shape.

Your backend still owns database writes, authorization, and business logic.

That boundary is deliberate.

Your customers' spreadsheet data stays in their browser

Bootstrapware Importer processes file contents client-side.

Bootstrapware may receive non-content session metadata such as the importer used, file type, row counts, or completion status. It does not receive:

the uploaded file,
the filename,
parsed rows,
normalized row data,
cell values.

That keeps the product simpler for us and gives you a much easier answer when a customer asks where their spreadsheet went.

Build it yourself when that makes sense

Bootstrapware is not the answer to every import problem.

Build your own importer if your workflow is extremely specific, importing is central to your product, or you need deep server-side ingestion pipelines and enterprise data onboarding.

Use Bootstrapware when the requirement is closer to:

“My customers need to upload spreadsheets and I need the data to arrive in a predictable shape.”

That is the boring part we are trying to make boring again.