1. We applied to YC and initially started work on what we referred to as "data-stack-as-a-service". The premise was to provision, configure, and maintain the different components required for a data stack: Data Warehouse, Integrations, Transformations, Visualizations, etc. We had a working product and a few paying customers. Ultimately we decided to pivot as we felt the market for this was only small companies with small budgets (many of whom might not even need a mature data stack).
2. Then we released a small open-source tool for Postgres that could easily send webhook notifications when data was changed (pg triggers sent websocket messages to a Go application). Off of this we dove deeper into database tooling and building a platform that offered branching, change management, and other modern features for Postgres. We also had a prototype and slightly larger contracts with a few early customers here. We decided to pivot from this for a few reasons, but ultimately we lost conviction in the idea and were more excited about data import challenges that came up during user interviews.
3. As you mentioned, we're now working on CSV import as a service. After building and maintaining CSV import tools many times ourselves, we believe there's an opportunity to provide a robust, pre-built experience. There are actually a few other products in the market today. Our initial focus is to be the most developer-friendly choice (a big part of why we're open source). We want the decision to leverage an existing service to be a no-brainer for any engineering team tasked with supporting CSV import.
If you're building a vertical SaaS and want to support import from a file, and don't want to spend time reinventing the wheel, this could be a big win. This would let new users bring in existing data from another SaaS (that supports CSV export) or where the incumbent is likely to be Excel. The development time it would take to make something like this solid, usable, and flexible enough to handle different formats would, in most cases, be better spent on building domain-specific functionality.
That use case perfectly describes the needs of the SAAS product my team is building. We have tons of domain specific features we want to build, and anything that frees up dev time for that work gets a look.
While I haven't yet seen the pricing for your link or the OP, this seems like a case where there aren't many negative tradeoffs.
There's so much more to CSV file import than just uploading and parsing - service like this can become backbone of any enterprise data exchange pipeline. For real mission critical use cases you need features like being able to ingest multiple gigabyte sized files reliably, quickly revert the import or switch to a specific version, detecting errors and recovering from partially corrupted files, detecting the new version is available, possibly importing just changes, publishing metrics on imported files to observability platforms, alerting if anything goes wrong...
If CSV import is not enough of a product (I believe it is) you can add exporting functionality (e.g. export this table to CSV and deliver to SFTP exactly once, but make sure to handle target downtimes) and you have an "Enterprise File Gateway" that could reduce development costs in many companies.
1. We applied to YC and initially started work on what we referred to as "data-stack-as-a-service". The premise was to provision, configure, and maintain the different components required for a data stack: Data Warehouse, Integrations, Transformations, Visualizations, etc. We had a working product and a few paying customers. Ultimately we decided to pivot as we felt the market for this was only small companies with small budgets (many of whom might not even need a mature data stack).
2. Then we released a small open-source tool for Postgres that could easily send webhook notifications when data was changed (pg triggers sent websocket messages to a Go application). Off of this we dove deeper into database tooling and building a platform that offered branching, change management, and other modern features for Postgres. We also had a prototype and slightly larger contracts with a few early customers here. We decided to pivot from this for a few reasons, but ultimately we lost conviction in the idea and were more excited about data import challenges that came up during user interviews.
3. As you mentioned, we're now working on CSV import as a service. After building and maintaining CSV import tools many times ourselves, we believe there's an opportunity to provide a robust, pre-built experience. There are actually a few other products in the market today. Our initial focus is to be the most developer-friendly choice (a big part of why we're open source). We want the decision to leverage an existing service to be a no-brainer for any engineering team tasked with supporting CSV import.