Historical strategy
This page contains explanations of changes in our strategy and older concepts.
See ”Strategy” for our current strategy.
What we learned from ’s strategy
This was written at the end of to explain how we arrived at our strategy.
In short: was “serving larger and smaller customers”, is “specific use cases”.
1 year ago, our growth was constrained by only being able to serve recent-vintage mid-size tech companies. Our strategy was to widen the range of customers we could serve:
- Serve larger companies by scaling to massive codebases and meeting complex enterprise requirements.
- Serve smaller companies with Sourcegraph Cloud.
We can now serve companies from large to small. Now, our biggest bottleneck is that most devs and companies don’t know they need code search or what problems it solves. We’re still just building and selling “code search”, which is a toolbox of features (search, batch changes, code intelligence, monitoring, code insights, extensions, etc.).
Also, this strategy required us to build things (such as scalability, CVS support, complex permissioning, and Cloud stuff) non-iteratively well ahead of customer usage. This was risky and painful, especially during rapid team growth. In hindsight, we were prospect-first, not customer-first. Being high-agency was tough when the information came from relatively few low-fidelity pre-sales conversations where we lacked time and goodwill to do all 3 of selling, learning, and challenging. Nevertheless, we did massively expand our addressable market and grow ARR due to teamwork and a great market opportunity. Next year’s strategy learns from these lessons to bring more value alignment and less pain and risk.
Big Code
In , Big Code dominated our pitch because we were targeting entire engineering teams at medium and large companies. It served its purpose. In , it will be a much smaller part of our pitch because we will instead focus on specific use cases (whereas Big Code is broad). Also, our target market has expanded to include smaller companies that don’t feel they have “Big Code”, and we’d rather highlight the use cases (which do resonate with the entire market).
We’re living in the era of Big Code: the amount, complexity, and value of code is growing quickly.
Tools and practices that were conceived before the era of Big Code will break down, leaving codebases that are huge but complex and brittle. Any change might shatter the whole thing. Developers become hesitant about making changes. Productivity slows, communication bottlenecks grow, deadlines are missed, and quality declines.
This is a new game. Companies that master this will thrive. Companies that don’t will fail.
For people as users of technology, Big Code is great. It means there’s more software out there, it’s more personalized, it’s faster, it’s on their desktop and phone and watch, it’s localized, and so on. But for developers, it’s way harder and takes way more work to build software than it did 10 years ago.