Here, there, and back again: Sourcegraph Cloud

Sourcegraph is a universal code search and intelligence platform. More than 800,000 developers in some of the largest companies around the world rely on Sourcegraph to search across and navigate their company’s code on all of their code hosts.

As an early-stage startup, Sourcegraph started as a cloud SaaS product before realizing that the company needed to do more to earn trust with companies’ private code. This led to a pivot towards making Sourcegraph open source and self-hosted. Companies could look at Sourcegraph source code for themselves and run their Sourcegraph instance in their own trusted environment.

This early decision, as well as a focus on Enterprise-scale customers, was crucial to gaining traction. Today, many of the world’s largest and most technologically advanced companies like Dropbox, General Electric, PayPal, and many more trust Sourcegraph with their private code.

I joined Sourcegraph shortly after the company closed a Series B funding round, and helped the company grow to a $125M Series D funding round to bring universal code search to every dev at every company of every size and scale. We heard again and again that for smaller companies with lean engineering teams that already use SaaS products across their stack, the ease of deploying through SaaS outweighs the benefits of self-hosting. And for us to bring universal code search to every dev at every company of every size and scale, Sourcegraph needs to be effortless for these smaller companies to deploy.

In response, we decided to make a big bet and build out Sourcegraph Cloud on top of Sourcegraph.com. This presented a big challenge: everything about Sourcegraph's product was built on the assumption that Sourcegraph is a self-hosted, single-tenant product.

Breaking assumptions

Building a self-hosted product involves a lot of assumptions that break when turning it into a cloud SaaS:

• All code on the instance belongs to the same organization.
• There is a person or team who can set up, orchestrate, and administrate Sourcegraph on the organization’s own stack and network.
• The instance admin will connect Sourcegraph with code hosts, and choose which repositories to add to Sourcegraph and make sure they sync properly.
• Running a global search on Sourcegraph will search across only your company’s repositories.
• All users on the Sourcegraph instance belong to the same company.
• A URL to a search result copied and pasted to someone else will “just work,” because everyone has access to the same code.
• There’s a high-touch, multi-stage sales process tailored for each customer.

The extent of this list of assumptions gave us an idea of just how big this challenge was, especially when we knew we wanted to keep “one Sourcegraph”—we didn’t want to split out into separate “Cloud” and “Self-hosted” products.

Big vision, incremental action

We needed to strike the balance between the long-term of what Sourcegraph Cloud would become and the concrete steps that would get us there. Our approach was to orient around the problems, identify the foundations, and to be really thoughtful about what we needed when.

Orienting around problems

Instead of orienting around action items or tactical steps, we oriented our efforts around problems that, when solved, would represent the “minimum lovable product” at each iteration, ultimately helping us to validate the overriding assumption that companies would trust us with their private code on a Cloud environment.

At the highest level, these problems and their dependencies looked something like:

Each problem was inherently cross-disciplinary and revealed a set of sub-problems we’d have to solve.

And each problem we solved would support each incremental step forward, all in a low-risk, high-confidence way that would help us to build momentum rather than rehashing the same problems again and again.

Identifying foundations

Once we had a roadmap of problems to solve, we took time to identify what we considered the “foundations”—those decisions that would influence all other decisions and ultimately accelerate future efforts, even if we didn’t act on them right away. Without identifying these foundations, we risked working ourselves into a corner by solving each problem in isolation, rather than as an incremental step within a bigger context.

For us, these foundations turned out to be mostly conceptual: what does it mean to “add code?” What about “connecting with code hosts?” How might that be the same, but different, for an individual user versus an organization? How does code visibility work? What’s the difference between what we’re doing here, and multitenancy? What decisions do we make now that will open up a future path to multitenancy?

We captured these decisions in async artifacts, such as an exploration of how multitenancy affects existing assumptions around roles and permissions, and an information architecture summary.

Async artifacts like these are a core part of effective asynchronous, remote collaboration. They make it easy to share and provide thoughtful, considered feedback, and to consistently revisit and build on our shared understanding of these foundations.

You ain’t gonna need it (yet)

Having both a clear roadmap of problems and a good idea of the foundations helped us to keep moving forward without feeling like we needed to solve every problem all at once. A big part of this meant constantly revisiting what we needed to do now, and what could be done later.

We knew we’ll need a strong invitation flow for organizations. The way we connect with code hosts can keep improving. And we know we’ll eventually need things like self-service payments and subscription management. But we weren’t going need it yet.

Initial results

We launched Sourcegraph Cloud for small-to-medium businesses in early 2022. Within a day, we achieved zero to one with our first contracted customer. Over the course of the quarter, we more than 100% outperformed our customer targets.

The pivot

While my team was working on Sourcegraph Cloud as a multitenant product, the company was also exploring “managed instances”—a way of deploying Sourcegraph where Sourcegraph set up and managed the instance ourselves, effectively delivering a different approach to a “cloud-based SaaS deployment.” This didn’t scale, because it was hands-on and heavily involved engineering to manage the instances, but there was growing customer appetite for managed instances.

Between the initial success of multitenant Cloud after launch and the growing demand for managed instances, we felt that our overall assumption was correct: customers would trust us with their private code in the Cloud.

The cross-disciplinary triad working on Sourcegraph Cloud—including myself, the product manager, the engineering manage, and a staff engineer—frequently revisited our goals and objectives with our work around multitenant Cloud.

In early 2022, we decided to challenge that it was the right decision to continue with Cloud as a multitenant product. While we had paying customers and were growing our commercial customer base, we felt that relative to the business priorities, capabilities, and revenue potential, it didn’t make sense as a strategic direct. The cost and complexity of continuing to build out the multitenant Cloud product to deliver a parallel experience as self-hosted massively outstripped the potential revenue and reduced complexity of instead pivoting to single-tenant cloud based on managed instances.

This was a decision we felt needed to be owned by the VP and Director level, because it had significant impact on roadmap planning and organizational structure. I created the initial RFC together with the product manager on the team, and we made the case to senior leadership.

Ultimately, this recommendation was accepted, and the company executed on the pivot. Today, single-tenant Sourcegraph Cloud is now the default deployment option for new customers, and many of our existing self-hosted customers are migrating to Cloud.