Startup survival, when to say yes to enterprise
🤔 How an early customer pushed Streamkap to BYOC.
Yesterday evening I joined a panel discussion hosted by Nuon talking about Streamkap’s journey to offering bring your own cloud (BYOC). It reminded me that while I’ve talked a bit about BYOC in this newsletter, we haven’t shared our story, and that it’s worth telling because it has some fun early-stage startup drama mixed in 🍿
When Ricky and I started Streamkap, the plan was to offer a SaaS on AWS, add multi-region support on AWS over time, and eventually provide Google Cloud and Microsoft Azure support.
We did were not planning on offering BYOC. A quick definition, BYOC, is an architecture in which the components of a vendor’s service which process customer’s data is hosted within the customer’s cloud while the control plane and management is run in the vendor’s cloud. The promise is the ease of SaaS with the security of self-hosted software.
Back in 2022, an investor introduced me to Jon Morehouse at Nuon. We had a great chat with him and shared some war stories about early stage startup life. Nuon’s mission was to make it easier for companies to offer BYOC. All of the sudden it seemed possible that we could offer BYOC, if we were deployed on Kubernetes. We actually considered building it then, proactively, without having had any customer requests yet…
Fortunately, we came to our senses. The company was just 5 months old and while we had a couple of alpha customers already and were able to get data from A to B, we literally had no UI. It was way too early to start thinking about new deployment models.
In 2023, our product improved a huge amount and for reasons unrelated to BYOC, we moved to a Kubernetes deployment model. Things were ticking along, we were signing new customers, including bigger companies.
One of those bigger companies, a large financial services company, tested the platform with our SaaS model and our on-prem database agent to connect to source systems. The test went well and they signed up for an annual contract in January of 2024. Great, exciting.
Then came the production deployment kickoff call…
Their DevOps person dropped the bombshell, “Our production databases can’t be connected to any outside service. It’s a non-starter for the business…”
Our hearts dropped, we had just signed this big customer and while we had been very clear about what our product offered throughout the evaluation, their team simply hadn’t confirmed if it was going to be possible to use the same architecture from testing in production. Oops.
One option was simply to tell them tough luck. We didn’t misrepresent our offering. They could either make the change on their side or just not use us, despite having signed up for a year. The other option was to build BYOC for them.
This is the sort of thing that can kill a young startup. It’s a classic area of tension for young companies, moving fast and doing what it takes to win while not building a bunch of custom things for their early enterprise customers. Did we want to go off and do a ton of work on BYOC to make this customer happy?
Fortunately, it proved not to be as critical a decision as that. We called up Jon at Nuon and dug in. With our move to Kubernetes, we could have BYOC live in less than a month. Ricky and I could also see that BYOC would be an effective selling tool for future enterprise customers. So we went for it.
Cut to today, that proved to be a very good decision. The initial financial services customer successfully deployed in production and renewed earlier this year. More importantly, BYOC proved to be very attractive for other new customers.
Through the year we signed other enterprise customers who simply couldn’t approve sharing their data outside their organizations. This was not too surprising but validated that it had been a good bet.
We also started to see companies that didn’t have hard data residency requirements but for whom a SaaS model would not be economically viable. Generally very high data volumes. It simply wouldn’t make sense for these companies to send their data outside their environments and pay the egress fees, run compute in Streamkap’s environment, then send data back in.
We are, of course, not alone in this trend. Databricks pioneered the deployment model in data, though they don’t use the term BYOC. RedPanda had been offering BYOC for some time. Warpstream, a Kafka-compatible streaming service built with S3 as its native storage pushed their BYOC as primary mode-of-deployment and BYOC competence was the reason Confluent gave for paying over $200m for the year old company.
Two other mega trends in data that we’ve talked a lot about, AI and Iceberg data storage, will also push more demand for BYOC. With AI, awareness of the value of enterprise data is higher than ever so there is more and more reluctance to share it outside. If a company chooses to store all their data in Iceberg in their own cloud storage, as opposed to a SaaS data warehouse, it’s less and less likely they will want their data to move outside their environment at any point in their data pipelines.
Warmly,
Paul Dudley
We’re looking at BYOC (though we’ve never used this phrase) right from the get go at Babbage. Reasons include cost, latency and (most importantly) data security.