DEV Community: Michael Kutateladze

Build vs Buy a CSV Importer in 2026: Is It Worth It?

Michael Kutateladze — Sat, 19 Sep 2026 14:05:57 +0000

I have spent the last nine months building a CSV data importer. Before that I worked in the same industry, and I watched import screens get built, shipped and patched. Embedded importers are an old idea, and I have read more than once that the category is dying. Then I ask engineers how they bring customer files into their product, and in 2026 I hear the answer I heard years ago. They are building their own.

A simple importer takes a couple of days

The reasoning is the same every time. We know which files our customers have. We have a fixed schema. With an AI assistant, a file input, a parser and a mapping screen take a couple of days.

All of that is true. For a small company with a few customers it is also the right call. You know the people who send the files, you have seen the files, and when one breaks you fix it quickly.

Growth changes the files

The trouble starts when the product grows. New customers bring files you have never seen, and nobody tells you before they upload.

One customer arrives with a dozen files at once. Another needs to load a single CSV with 500,000 rows. One file has rows that came out a value short, so everything after the gap sits a column to the left. One has no header row at all. One has a title and two blank lines above the headers. Dates come as 3/4 in one export and 4/3 in the next, and numbers switch between a dot and a comma for the decimal.

Each of these is a ticket. Each fix is small. The tickets never end.

Validation grows with the customers

The schema was fixed on day one. The rules around it keep moving.

One customer needs a custom check on an account number. Another needs a check that calls your API, because only the server knows whether that SKU exists. Now validation is asynchronous, it has to batch its requests, and it has to stay out of the way while the person keeps editing.

Then come the values every product shares. A country can be written as Germany, Deutschland, DE or DEU, and your database wants one ISO 3166-1 code. A phone number comes with spaces, dots and brackets, and you want to store E.164. Dates want one format on the way out, whatever they looked like on the way in. There are standards for all of this, and somebody on the team has to read them.

The browser has to keep up

After the data questions come the experience questions. The person who uploaded 500,000 rows expects the page to keep scrolling. They expect to fix a bad cell in place, the way they would in Excel, without downloading the file and uploading it again. They expect filters that show only the rows with errors, undo when a fix goes wrong, and copy and paste that behaves the way it does in a spreadsheet.

A large file stalls a browser in more than one place. Parsing on the main thread freezes the interface. The parsed rows take several times the file size in memory. Rendering them in DOM nodes ends the conversation.

The full version takes months

You can build all of this yourself. Nobody doubts that. A team can ship an importer for its own happy path in three weeks. The road from that importer to one that handles files from customers you have never seen before is an open-ended project, because the list of files is open-ended. It takes months, and it takes months with AI too. AI writes the first version in days. It does not collect the broken files for you, and it does not decide how a grid should behave with a million rows in it. I know the number because I have been paying it for nine months, full time, on this one problem.

Building is still right for some teams

If one known partner sends one known file shape, stay with your two day importer. It fits the job, and nothing in this post applies to you yet.

If your import is a scheduled pipeline with SFTP drops and recurring feeds, that is server work, and a browser importer is the wrong shape for it.

If import is the product your customers pay for, build it and own every line.

What the months cost

Take $60 an hour as a low estimate for an engineer. A month of focused work is 160 hours, so an engineer month costs $9,600, plus $100 for the AI subscription. Call it $9,700.

Be optimistic and say the full version takes two months. That is $19,400 spent before the first customer uploads a file. After launch the tickets start, and your team is the one fixing them. The time they spend on the importer is time they do not spend on your product.

What buying costs

The market has changed. Importers are turning into a commodity, and a good one no longer needs a sales call.

I sell one, so read the next number knowing that. Updog costs $19 a month per production domain and is free in development. A product serving ten customers, each on its own domain, pays $190 a month.

For those ten domains, one engineer month pays for more than four years of the subscription, and two months pay for more than eight. Drop the rate to $40 an hour and one month still pays for almost three years.

The decision belongs in a budget

For everyone outside the cases above this is a business decision, and it needs no heroics. "I am an engineer, I will build it myself" is a true sentence. The same engineer costs $9,700 a month.

Updog is built around the problems that come with importing customer files into your product and starts at $19 a month. It deals with messy files, runs your validation, and keeps the browser fast on large imports.

So before you start building, ask yourself whether you are ready to spend two months and thousands of dollars on your own importer, or whether you would rather pay from $19 a month for a maintained product with support when you need it.

AI disclosure: The ideas, experience and conclusions in this article are my own. AI was used to help edit, structure and refine the writing.

The First CSV Importer You Write Breaks on Real Files

Michael Kutateladze — Thu, 17 Sep 2026 15:02:53 +0000

I spent the past nine months building a data importer. It is the screen where a person brings records they already have into a web app, such as a customer list or a price list exported from another system, as a CSV or Excel file. The app reads the file and turns every line into a row it can store.

Reading a CSV looks like a small job, and a first version can fit in six lines.

const text = await file.text();
const { data } = Papa.parse(text, {
  header: true,
  dynamicTyping: true,
});
setRows(data);

This is a reasonable first CSV import. PapaParse reads the text, header: true turns every line into an object keyed by column name, and dynamicTyping: true turns numeric strings into numbers. A test file goes through it cleanly, because the developer wrote that file to fit the code.

When the file comes from a system you control and already matches the shape your app expects, this code can be enough. A file from someone else follows the conventions of the software that produced it, such as how it writes dates, decimals, and IDs, and each of those conventions can break this code in its own way.

Type inference strips leading zeros

Some values look like numbers and are not. Customer IDs, ZIP codes, and product codes are made of digits, and the zeros at the front belong to the value. A parser that converts everything numeric into a number throws those zeros away.

A customer export holds a customer_id column with the values 00123, 00401, and 07030. dynamicTyping tests each value against a number pattern, and on PapaParse 5.6.0 that pattern accepts leading zeros, so "00123" becomes 123.

The row still looks valid. It stops matching customer 00123 the moment the app uses the value as an identifier.

The import keeps the raw cell text and lets the schema decide the type. A field declared as an ID stays text. A field declared as a number gets checked as a number, and 00123 in that field becomes a value to flag. The parser sees one value at a time and has no way to tell an ID from an amount. The schema knows which field is which.

In an Excel file, a cell formatted as 00000 stores 401 and shows 00401, so the importer reads the formatted text.

Some zeros are gone before the file reaches you. Microsoft documents that Excel "automatically removes leading zeros", so a CSV that passed through Excel can arrive holding 401. Nothing in that value says the ID had five digits. Your own code pads it back, because only your app knows the width.

The whole column reveals the date format

A date written as 03/04/2025 means 3 April in the UK and 4 March in the US. The file does not say which convention it follows, and JavaScript picks one on its own.

An export from a UK system writes dates day first. The obvious conversion hands each value to the Date constructor.

new Date("03/04/2025"); // Tue Mar 04 2025
new Date("28/11/2025"); // Invalid Date
new Date("15/01/2026"); // Invalid Date

In V8, the engine behind Chrome and Node, the first value parses without an error and lands on 4 March. The file meant 3 April. The other two fail, so one column produces a silent wrong date and two errors.

One value cannot settle the format, because 03/04/2025 is a valid date read either way. A sample from the whole column can. The importer takes a sample of values from the column and lets every candidate format try to read it, day first, month first, year first, and the rest. The format that reads the most values wins. 28/11/2025 has no 28th month, so month first fails on it and loses the count. Day first reads all three, wins the column, and 03/04/2025 becomes 3 April for every row.

A column holding only 03/04/2025 and 05/06/2025 reads fully both ways, and the data cannot break that tie. A convention from outside the data has to, such as the locale of the browser. The importer should report that it guessed, because a wrong guess produces dates that look valid.

The whole column reveals the separators

Countries write numbers differently. One thousand two hundred thirty-four and fifty-six hundredths is 1,234.56 in the US and 1.234,56 in Germany. The dot and the comma swap roles, and code written for one convention misreads the other.

Price columns from different systems hold 1.234,56, 1 234,56 with a non-breaking space, €1,234.56, and (250,00), which accounting software uses for a negative amount. parseFloat reads each of them from the left and stops at the first character it does not expect.

parseFloat("1.234,56");  // 1.234
parseFloat("1 234,56");  // 1
parseFloat("€1,234.56"); // NaN

A validator catches NaN. 1.234 passes the same check, because it is a valid number, and it is a thousand times smaller than the amount in the file.

The column votes again, and this time the candidates are pairs of marks, one that groups thousands and one that starts the decimals. Dot and comma is one pair, comma and dot another, space and comma a third. A pair reads a value only when the digit groups sit where that pair expects them, so 1.234,56 fits dot and comma and fails comma and dot. Before the vote, the importer strips the currency symbol, normalizes the non-breaking space, and turns (250,00) into -250.

The column settles values that look identical on their own. 1,234 means 1234 in a column that also holds 1,234.56, and 1.234 in a column that also holds 1.234,56. A column of nothing but 1,234 ties the way dates do.

Value mapping works on distinct values

Some fields accept only a fixed list of values, such as a department, a status, or a country. People type those values in their own words, with different spelling, case, and abbreviations. The importer turns every variant into one of the values the app accepts.

The file's Department column already matched the department field by its header, and a lookup table converts the words.

const DEPARTMENTS = { Engineering: "eng", Sales: "sales" };
row.department = DEPARTMENTS[row.department];

The column holds Engineering, engineering, Eng, R&D, and Enginering. The table finds the first and returns undefined for the other four. The header matched, and the values inside the column still use the words of whoever typed them.

The importer collects the unique values of the column, resolves each one once, and applies the finished mapping to every row as a lookup. A million rows with five spellings of a department need five decisions. Fuzzy string matching that ignores case pairs engineering and Enginering with Engineering.

String similarity alone does not tell you that R&D means Engineering, or that Eng is short for it. That knowledge belongs to your domain. It reaches the mapping through a synonym list you keep, through your own logic, such as the mappings the same customer confirmed last time, or through the person importing the file, who picks the value by hand.

The browser decodes every file as UTF-8

A file on disk is a sequence of bytes, and an encoding is the rule that turns those bytes into letters. Older systems and different countries use different rules. When the app reads a file with the wrong rule, letters such as ü and é come out broken.

The import code at the start of this article reads the file with file.text(), which always decodes it as UTF-8. A CSV written by an older system in Windows-1252 stores ü as the single byte FC, which is invalid in UTF-8. The decoder swaps it for a replacement character, and Müller arrives as M�ller. The opposite mistake, UTF-8 bytes read as Windows-1252, turns Müller into MÃ¼ller.

The replacement character is final. Once � sits in the string, nothing recovers the letter it replaced, so the decision has to happen while the bytes are still in hand. The importer checks for a byte order mark first, because it can identify several Unicode encodings before any guessing is needed. Then it tries UTF-8 in strict mode, where an invalid byte makes the decoder throw.

const decoder = new TextDecoder("utf-8", { fatal: true });
const text = decoder.decode(await file.arrayBuffer());

If strict decoding throws, the bytes are not valid UTF-8. Only then does the importer infer a legacy encoding from the bytes with a detector such as chardet, and decode again with the label it returns.

Large files break both parsing and rendering

Every fix so far works on a file of a few hundred rows. A file with a million rows asks the browser to read, process, and show all of it while the page stays responsive.

The import code at the start of this article runs on the main thread, which also paints the page and answers clicks. As the importer gains decoding, parsing, format detection, and value mapping, doing that work on the main thread turns it into one long task, and the tab stops responding until it ends.

The importer hands the File object to a Web Worker and decodes and parses there, so the page keeps painting. Some cost stays on the main thread. On 4 September 2026 I ran a 108 MB CSV with one million rows and eleven columns through a worker in Chrome 151. The main thread stayed free while the worker parsed, and still hit one 389 ms task when the parsed rows arrived back. A worker that reads the file in one call also holds the whole file in memory.

The rows then reach the second limit. A normal DOM table does not scale to a million rows, because every cell it renders is an element the browser lays out and paints. The grid has to limit rendering to a small window around the visible rows and work out the rest from the scroll position. A virtualized list does that with elements, and a canvas grid does it with pixels.

An importer answers what the data means

Other files break a simple CSV import in other ways. A report can place its header row several lines down, under a title and a blank line. Two columns can share the header id, and PapaParse renames the second to id_1, which no field in the app expects. A short row can shift its values into the wrong columns. An Excel workbook can hold several sheets, and only one of them holds the data.

A CSV parser answers whether a file can be read. An importer has to answer what the data means, what is wrong with it, what the person can fix, and what the app should receive.

I learned most of this while building Updog, a client-side importer for CSV and Excel files.

I wrote this article with the help of AI.