Show HN: Csvbox.io – CSV import button for a web app, SaaS or API
csvbox.io
csvbox.io
I have been developing Shopify apps for the past 5 years. Currently working on a new project csvbox.io to solve a common problem that I have faced many times.
There have been many applications where we needed to accept spreadsheets from the end customers. Building an importer from scratch is time consuming and maintaining it is another headache. Moreover, the import process for the customers is messy because they have to read the docs and follow the upload templates. In many cases, after long support email threads we ultimately have to manually accept, clean and input the data.
As a solution I built the csvbox.io import widget. Its a no code, drop-in widget that allows you to accept files in minutes. Users can upload files, match columns, validate data all in a few clicks. You receive ready to use data in your app. A better experience for your customers, fewer headaches for your team!
I launched it only a few days ago. Happy to receive feedback on everything - UI/UX, features, pricing etc.
Does / will your system import images in spreadsheets?
Currently, the widget does not support images. Honestly, we havent yet thought about it. Now that you have raised this point, we will surely discuss it.
Easy to miss the drop target though (testing this at a bit past midnight) – seems like it would be easy to make that larger (or just make the whole window a drop target for the CSV)
Making the entire window a drop target is a neat idea. I am noting it down for implementation.
We'll take on this once we hit a few milestones.
We are not using webworkers. Instead first we upload the files to our backend and then push them to the destination app.
1. Escaping in csv 2. Month names will be treated as string.
This has got us thinking for more such scenarios. Thank you!
Multiple datasets in the same csv but instead of adding extra columns put in some breaks in one long column. So you start scanning for empties, skip some metadata and start reading again... Sometimes it is wild.
Could the app handle this one?
"First Name","Last Name","Address","Town","Postcode"
David,O'Leary,"12 Acacia Avenue",London,NW5 3DF
June,Robinson,"14, Abbey Court","Putney",SW6 4FG
Greg,Hampton,"",,
Stephen,James,"""Dunroamin"" 45 Bridge Street",Bristol,BS2 6TG
Daisy,Smith,"Flat 6,
Porchester Court,
24 Dragon Road",Newcastle,NE3 4FG
edit: I tried it with the csvbox.io demo - it seemed to deal with it ok!
- in your embed code snippet, you have `There was some porblem uploading the sheet` -> the word "problem" is misspelled
- the embed code includes https://js.csvbox.io/script.js which has two console.log debugging calls which could be removed in production
- when adding columns to a new sheet, it would be neat to be able to paste the header line from a CSV file and for the columns to be created (this wouldn't help with the Column Type or Required options, but at least the Column Name would be set/wouldn't have to be typed one by one)
- also, when adding columns, it would be great to press the enter key after typing a Column Name to save/close the modal
I agree with most other commenters' feedback re: pricing, especially https://news.ycombinator.com/item?id=27133717 i.e. making the Sandbox much more generous. I was surprised to see only 5 rows imported initially, and thought it was a bug on your side (i.e. I thought only the first 5 rows were parsed)
Congrats on the launch!
I will get the bugs fixed.
I have also noted down the suggestions on column name and Keypress. We will implement them soon.
Pricing restructure is also on the cards.
Once again, thank you!!!
How are you dealing with character encoding? I uploaded a CSV file that has an utf-8 character in the name of a column, and in your import flow, under "File Columns", the column name appeared incorrectly encoded (i.e. it's been latin-1'ized)
My file is most probably missing the UTF-8 BOM. I'm not sure what a good option is here.
Have an advanced setting for Sheets (on your site) and pre-set the uploaded files' encoding?
Great idea to make it its own product!
Best of luck!
We will soon be introducing plans with higher row limits as well.
Neither of them work out, business-wise.
I agree about lifetime. I’m suspicious of lifetime offers. I don’t think you are really going to support me in 2060! Is there anything from 1980 like this that is still supported?
This is our introductory pricing that will evolve over time. Here is our dilemma - on one hand we want to target indie developers, side projects, bootstrapped startups (that are cost conscious) and on the other hand we want to maximize the earning potential and also not look like a low value product.
The utility of what you are offering is significant. If I'm a 'cost conscious' startup and I need CSV upload functionality then I either write the functionality myself (30+ hours of dev time + ongoing maintenance?) or I use your service.
If the product works as advertised, you could charge $19/month for a basic plan and that will always be better value than 30+ hrs of time a developer will have to put into the CSV problem with all its annoying edge cases.
My suggestion is to modify the free plan such that users can upload 10k+ rows per upload, but only 20-30 times per month. Then your 'cost conscious' startup with only 5 customers can test your solution, know that it works for non-trivial amounts of data, and happily fork out $19/month when they hit 20+ customers a month and become less 'cost conscious'.
When I use the test file, it makes all fields required. It should probably accept empty/unknown values, no? (I just saw you commented on that elsewhere)
In my experience, the manual validation feature is not that useful for most use cases, where the sheets have lots of rows. My clients have always preferred to have a list of validation errors / row numbers, modify the source spreadsheet itself using all the power of Excel, and reupload.
I think the true value of this tool will be in how well it deals with messy data. A common problem is character encoding. At the moment, when I put in Polish characters in the file "EACĄŚŽĄĘĆĄ", it gets displayed as "EACÄÅŽÄÄÄÄ" - need to fix that.
The validation could be more robust. Common data types (age, first names) could easily have their own specific rules. At the moment, you can put negative or out of range values for the age, or special characters for the name. And what would be really valuable is detection of outlier values - to tell the user if a value is three times longer than other values in the same column, contains unusual characters, etc.
As for features, I would like a PDF import (you can just take one of the open source pdf2excel libraries, then write a bit of smart code to detect&strip the headers and footers - took me 3 days to implement last time and the client loved it ;) Doesn't need to cover all cases to be very useful.
And of course, file upload is a must, ideally allowing multiple columns IMAGE1, IMAGE2, etc.
You can configure the validation criteria for each column via the app admin. Simply mark the column as 'not required' to accept empty values.
I have noted down all your feedback for fast implementation.
Cant thank you enough!
PapaParse has no built is validations. With csvbox you can define a data model in the admin. The users can match columns, validate data and submit the file without you having to write a single line of code.
The service looks interesting, but I'm wondering if there's a technical reason why it's a SaaS. CSVs could be parsed entirely on the client, and it should be possible for .XLS/.XLSX as well. If not with pure JavaScript+Web Workers then surely with WebAssembly.
Doing this traditionally on the backend is fine of course, but as others have mentioned, trusting you with potentially sensitive data is a hurdle for many companies and individuals.
To be honest, we haven't thought about the possibility to work everything client side. Its an idea worth exploring.
Our aim is to integrate the importer with multiple destinations such as databases (MySQL, PostgreSQL, S3 etc), APIs (custom, Zapier, GSheets, Airtable) and others (FTP, Email etc). Coding server side would be easier and faster.
Moreover we plan to introduce on-premise deployment options in the future.
Then again, enterprises that deal with sensitive data don’t just allow employees to access that data via a web browser (or should not) and especially not through a modern one. So it would be a huge pain to figure out which browsers are capable of even supporting Wasm and other modern tech.
I completely understand your position. Self hosted version is in our long term development pipeline.
Data security is important to us. We have the option to get the data deleted as soon as it is pushed to your app. Please check our note on user data - https://help.csvbox.io/legal/data-policy
The validation rules for any sheet can be controlled via the admin dashboard. You can choose to mark any column as required/not required.
To demonstrate the validation capability we enforced 'required' validation on the 'Age' column in the demo.
The app validates the spreadsheet data against the data model rules configured by the developer and shows the errors to the users. The users can edit the data in the widget itself to resolve the validation errors before submitting the file. This ensures that the submitted data is clean and ready-to-use.
Eg Mac Numbers app is really bad about this where it will sometimes insert the file name as a “title row”
Currently, once the users upload the file, they have the option to delete any rows that they do not want, by clicking the remove button in the widget itself. Once the data is clean they can submit the file.
I recently gave one pass at a Jira CSV import and went with the API instead.
Excel is the ultimate no-code solution.
1. We are focused on indie developers and startups. Our pricing is reflective of that. 2. csvbox is a no code widget. The entire column model and validation requirements can be defined in the app admin without the need to write a single line of code.
P.S. others promote self hosted, but I wouldn't bother if we're you. I did esignatures and lots of people asked for it, so we built it, but no indie/startup dev ever bought it. The only people who only ever truly implemented self hosting were enterprises. My 2 cents.
Charge more. Get rid of the $9/plan.
Saying this as a SaaS operator who could use something like this, and who pays much more for other apps.
What according to you should be the minimum pricing tier?
(As recommended in Jason Cohen’s classic and awesome talk “Designing the Ideal Bootstrapped Business”: https://youtu.be/otbnC2zE2rw)
Customers at very low price points (such as $9/month) tend to churn quickly, and, counterintuitively, send more customer support interactions per customer than at higher points. You’ll never earn enough from them to cover your customer acquisition costs.
Getting rid of the cheap plan also removes the, shall we say, more difficult customer.
As a dev, I have the opposite opinion: The low-end pricing is a barrier to adoption. $9/mo isn't much, but it's the difference between "Oh cool, I can immediately use this in some of our side projects!" and "Oh, I have to request budget approval for this, explain what it is to superiors who might not be in the IT dept, answer questions about why we don't do just build it ourselves, answer questions about vendor support and lock-in, etc."
It would cost more time for me to jump through all those hoops than to just use a standard CSV parsing library -- even though the workflow is vastly inferior -- because it's much less bureaucratic.
Other services often provide a more generous free tier so that devs (the first ones to try something, often) can use it in a real-world project, fall in love with it, and then sell the paid version (which could be much more than $99) to their superiors only when the prototypes have proven valuable enough to make a solid sales pitch.
I'm not a business consultant by any stretch, just letting you know that as a dev, I'd probably never bother using this because of the bureaucratic headaches involved with your pricing structure. Just my 2c.
We will surely have a relook at the pricing model.
"There was a porblem uploading the sheet"
I've just gone though your `example.csv`, and have this feedback:
- the (row) "Remove" action seemed like data column to me, because it is placed adjacent to the data. I would separate the actions completely from the data. I'd probably avoid the "X" within the column, as again, it looks like data. Admittedly, users probably know the content of the CSV they are uploading, so this might not be too big a concern. But the UX/semantics of styling the "actions" the same as "data" seems like it will lead to confusion. At the moment, the only action is "Remove", so I might drop the Remove "column", just put a button labelled "Remove"; after all, the "X" is already a "button" (as a link). That said, bulk actions a chore to implement and so I suspect getting this working nicely will probably be a big draw for your target market. Whether it's checkbox boxes with a single select drop down to apply an "action", or a select drop down on each row (painful UX, I'd think). Hopefully you already have a revision on your roadmap.
- The wording "File has 1 invalid rows. Please resolve the errors before uploading." is occurring after the user has already uploaded the CSV, so I think it should be adjusted. At this point in the workflow, I'd probably stop referring to "File" (the user is only concerned with the data at this point). I'd suggest more succinct wording, perhaps: "1 invalid row must be resolve before continuing."; or "...before you may continue.", if you prefer using the second person in the app messages.
- The full screen modal for a small number of rows forces the user to hunt for the buttons and mouse a far distance. I realize for most data, the modal is likely to be the entire screen (and multi-page), but nevertheless, I would probably make the modal shrink to the data. As a consideration for your market: I've written apps which use CSV for only ~25 rows, and I would still consider using this because the user interaction for sanity and clean-up was still code I would've prefer to skip writing.
- I would increase the number of rows permitted at the lower tiers. Maybe you are analyzing the imports and have a lot of information about the pricing breakpoints and segmentation, but my hunch would be that fewer imports with more rows might entice people. I can think of apps which might have only 5 or 10 imports per month, but need more than 50K rows per import, but it's a pretty big jump to Basic, so you might miss those customers.
- I would make the corrected/edited CSV available for download (by the customer) at the end of the import. If anyone needs to re-import, it will surely be annoying to re-correct it during import; or even to remember all the corrections they made during import and go back and correct their original spreadsheet (or other data source).
- Would be nice to see PostgreSQL on your destination roadmap :-)
Again, this seems like a really good idea to me. I wish you success!
I am adding all of the 6 points that you have raised in our roadmap to be developed in the near term.
I just thought of one more comment: have you tested the UI/UX when there are enough columns so that the modal must scroll? In that case, the actions adjacent to the data will also probably not work very well; i.e., I would not make the user horizontal scroll to access the actions. Meaning, I think you'll definitely want the actions separated from the data, so that the data scrolls while the actions remain fixed position.
Sorry I don't have more time to experiment with actual data types. I'm sure you can do a lot here too. I once dealt with an app that imported a CSV with geographic coords [lat,long]. During import validation, we showed a map to allow for correction / precise placement. That kind of richness would be great. To be validated with your market, of course.
Good luck!
We plan to add advanced validation capabilities as and when we get use cases demanded by real customers. Its a huge project in itself!
Thanks once again!
Your point is well taken. We will upgrade in the future.