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.
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.