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.
