Founder Interviews: Sid Sijbrandij of GitLab

Learn how Sid Sijbrandij and the GitLab team went from launching on HackerNews to a $100M Series D in 6 years.

Davis Baer: What’s your background, and what are you working on?

I’m originally from the Netherlands but have lived in San Francisco for nearly four years now. I’ve been involved in a number of different ventures — from selling programmable infrared receivers to starting a recreational submarine company — but seeing the first Ruby code in 2007 changed everything. I loved it so much I learned to program and made it my profession.

This was a natural stepping stone to GitLab, which I co-founded. The first single application for the entire DevOps lifecycle, GitLab is built on open source, leveraging the community contributions of thousands of developers and millions of users to continuously deliver new innovations. Product, Development, QA, Security, and Operations teams use GitLab to work concurrently in a single application. Everyone contributes to a single conversation, instead of managing multiple threads across disparate tools. There’s also complete visibility across the lifecycle with a single, trusted source of data to simplify troubleshooting and drive accountability.

We recently raised $100M in Series D round funding, led by ICONIQ Capital, to deliver our vision of beating nine other best-in-class products with our single application.

What motivated you to get started with GitLab?

GitLab got started because our co-founder, Dmitriy Zaporozhets, needed something to collaborate with his team, so he could focus on his work, instead of the tools. So he started to build GitLab as the solution for this. When I first saw it, it made sense to me that a collaboration tool for programmers would be open source so everyone can contribute to it. I asked the Hacker News community if they were interested in using GitLab.com and hundreds of people signed up for the beta. After the first year, it was clear that this SaaS offering wasn’t making enough money. Luckily we had large organizations that self-managed their GitLab installation who contacted us for more features, so we changed our model to cater to them.

What went into building the initial product?

I bootstrapped GitLab with $100,000, but even before that Dmitriy had built the first iteration on GitHub, with more than 300 contributions in the first year.

It started as a collaboration platform for developers but has grown into a single application for the entire DevOps lifecycle. We didn’t anticipate a single product would have all these emergent benefits in visibility, efficiency, and governance for our users. We only combined our two products into one because one of our engineers said it would be more efficient for our own development process. Only after doing this we gained the insight in how much better it was for our users.

While GitLab was originally written in Ruby, some performance-sensitive parts have been rewritten in Go. Ruby enabled GitLab to keep bringing great improvements to the platform month after month. The extensive testing suites and libraries keep the project maintainable at scale.

How have you attracted users and grown your company?

GitLab was launched as a Show HN of GitLab.com. We’ve always tried to see where our users were and talk with them there. When you find people who have a need for your product, you start by bringing it to their attention. Then you enter a phase where they care about your product, and they start asking you for more — that’s easy, that’s the honeymoon phase. Now we’re getting to the phase where people think of GitLab as a finished product, and expect that it should be perfect, so they tell you what you could be doing better.

There’s a fine balance between delivering what users want, improving on existing features and functionality, and building visionary features that maybe no one is asking for. Don’t lose track of what your customers are asking for, but if you focus too much on that you end up with too little visionary stuff. If you build the right company with the right team, then everyone will be listening to your customers and screaming, “Let’s build the things customers want!” So it becomes leadership’s task to focus on what we need to do in order to be a better company in five years.

What’s your business model, and how have you grown your revenue?

We experimented with a few different models before settling on one that works. We started out by taking donations, which Dmitriy used to refer to as “ice cream money” because it was $7 a month. We got up to $1,000 in our most profitable month after a big drive, but it just wasn’t sustainable for a company with multiple employees.

We also tried charging a fee to build requested features from users, but when people found out there were others making the same request they would drop their order with the expectation that another user or company would pay for it. We then moved to a support model, but this was a catch-22 — as we improved the product, fewer people needed support. No business model should depend on an imperfect product, as this would ruin the brand.

In the end, we settled on open core, where some features are paid. The hard thing was deciding which features are paid. I think after many years we now have a good way to determine that. The feature aimed at an individual contributor, it’s open source. If it’s aimed at a manager, it’s in our Starter tier. If it’s aimed at a director, it’s in Premium. And if it’s aimed at a C-level exec, it’s in Ultimate. That brings a lot of clarity and it seems to work really well, but it took us a while to figure that one out.

We also have some paid subscription plans for GitLab.com for additional features and enhanced support.

What are your goals for the future?

Since raising a Series C round last year, we’ve delivered on our commitment to bring a single application for the entire DevOps lifecycle to market. With this latest funding round, we will continue to improve upon our suite by building out our management, planning, packaging, monitoring and security features for a more robust DevOps application. Our product roadmap is public, so you can see what we’re working on for upcoming releases (we ship a new version every month on the 22nd), and we also recently shared our product vision for the future (with the caveat that everything is always in draft and we’ll keep tweaking it as we go along and gather feedback).

One of our biggest challenges is that many people still think of us as just a version control tool. We are expanding our offering all the time, as well as improving our reliability and user experience, so I’d encourage anyone not familiar with GitLab’s other features to give it a try — you might be surprised at how much has changed.

What are the biggest challenges you’ve faced and the obstacles you’ve overcome? If you had to start over, what would you do differently?

In hindsight, I’d rather have started GitLab.com a bit later. We’ve grown so fast since then that we’ve been behind in making a great experience for our users. I would focus on people running GitLab self-hosted, and start GitLab.com when we were ready for it. I’d rather have people not use our product than using the product and not being absolutely happy about it. It’s not about users, it’s about happy users. If not 100% of the users are happy, we’re not doing a good enough job.

There’s also the ongoing challenge of scaling — we’ve already grown from a company of fewer than 10 to nearly 400 employees, and we’re still hiring. Our culture and communication is particularly important as an all-remote organization, but could easily take a back seat to other priorities, so we have to be vigilant about it. We’ve cycled through several approaches to our company call, for example, and we’re still figuring out how best to scale it. Fortunately, iteration is one of our company values — it’s expected that we’ll keep tweaking things as we grow.

Have you found anything particularly helpful or advantageous?

Joining Y Combinator was essential for us. It opened up lots of doors that would otherwise have been closed. For example, the seed round of investors we have with people like Ashton Kutcher and Michael Arrington — I don’t think they would have even considered us if it wasn’t for Y Combinator.

We were also lucky to have our first board member, Bruce Armstrong, operating partner at Khosla Ventures, who was very thoughtful with us and worked really hard to help us every step of the way. That felt very empowering and it’s not always the case with venture capitalists, so that was awesome.

Sometimes it’s helpful just to reach out: I sent Matt Mullenweg, CEO of Automattic, the makers of Wordpress, an email saying “Hey, can we talk?” Now he’s on our board. If you show you’ve done your homework, like mentioning why you want to talk and reference a blog post or something they tweeted, people are more likely to respond.

What’s your advice for entrepreneurs who are just starting out?

If you are or have a technical co-founder, I highly recommend joining Y Combinator.

Most people wait too long to bring their product to market and their cycles are too long. One of GitLab’s core values is Iteration, which helps speed things up.

For advice about running a company, I recommend the book “High output management.” You can see other books I’ve found helpful here: https://about.gitlab.com/handbook/leadership/#books

A lot of the lessons we learned can be found in our public company handbook, which now runs to over 1,000 pages.

Where can we go to learn more?

Our website is about.gitlab.com, and you can also check our blog for news and stories from our engineers and users. Follow us on Twitter, and feel free to ask me questions in the comments below! We also always welcome people to contribute to GitLab.

This interview is brought to you by OneUp, a tool to schedule and automatically repeat your posts on Facebook, Instagram, Twitter, Pinterest, LinkedIn, and Google My Business