The desolation of SPOG

Gitlab's remarkably transparent company handbook and public financial filings tell an ambitious tale of its future. If Gitlab succeeds in achieving its vision, it will have slain a fearsome business dragon. But is Gitlab's quest even a good idea?

Gitlab's future

The vision

Gitlab wants to build a single application that supports every phase of the software engineering process in modern tech companies. Today, these phases loosely correspond to several disparate product categories, but Gitlab wants to combine them all together into a single product offering.

In its vision statement, Gitlab describes how it's going to build its platform in two steps.

First, by developing point solutions in each phase within its single product, Gitlab will consolidate the software infrastructure category, forming "a consistent and desirable user flow".

Then, through this combination, it will create a new product category: "the consolidated toolchain". This will turn Gitlab into a unique, comprehensive software development platform. For developers, it might be the only app they visit on a daily basis.

Gitlab defines nine rings phases in the development life cycle: Plan, Create, Verify, Package, Secure, Release, Configure, Monitor, and Govern.

Through the power of these categories combined, Gitlab hopes to become a "single pane of glass" for research and development (R&D): or a "SPOG", for short.

The competition

Gitlab's business plan puts it in direct competition with a large swath of the software industry: R&D infrastructure providers. Their list of adversaries includes DataDog, ServiceNow, Atlassian, GitHub, JFrog, Docker, and Splunk.

If we open the door to more aspirational participants, AWS, GCP, and Azure would also love this business. Today, these public cloud platforms are more focused on competing amongst themselves. Still, they're worth mentioning—all three have similar product offerings in the R+D infra space, though admittedly they're not very popular (sorry, AWS CodeCommit).

This is a well-funded, competitive market. Gitlab will not succeed without a struggle, and many of its competitors are plenty big enough to offer staunch resistance. Some napkin math suggests that Gitlab is up against companies who sum to over 200x Gitlab's own current market capitalization.

Fortunately, Gitlab's not exactly bankrupt, either.

The coffers

As of January 31st, 2023, Gitlab has almost $1B in cash, cash equivalents, and short term investments on its balance sheet. At that time, Gitlab also reported $130M in net accounts receivable. This bankroll is enough to fund multiple years of Gitlab's operations—and that's if you ignore the revenue.

However, as the profit and loss diagram above demonstrates, Gitlab's revenue can't be ignored. In its most recent fiscal year Gitlab earned $424M, a number that's growing 65% year-over-year. Gitlab still operates at a loss—this revenue is not enough to cover expenses—but that's a remarkable growth rate, especially for a company this large.

All of which is to say: Gitlab has plenty of cash to spend on building its SPOG.

How Gitlab could spend it

When expanding an existing product into a new category, there are no solutions—only trade-offs. Here, the trade-off exists between the control you retain over the resulting product and the money you're willing to spend. Every company strikes its own balance. Here are three common approaches.

Acquisitions

Acquisitions are a straightforward way to broaden your product offering. Simply go out and buy a company that built a product in the space you want to enter, then integrate its product into yours.

From an engineering cost perspective, this may be the cheapest option. However, it can be difficult to control the details of the final product with this approach. Typically, stitching products together after they're built degrades the quality and cohesiveness of the user experience.

Gitlab doesn't have to worry about that, though, because Gitlab's acquisition policy requires acquired companies to shut down their old product within 90 days and re-implement it from the ground up in Gitlab's own Ruby-dominated tech stack.

This policy seems unpalatable—Gitlab hasn't made any major acquisitions since its IPO.

App store

As previously discussed, building an app store into your product is another way to broaden your offering. With this approach, you give up some amount of control over your product to third party developers in exchange for market-driven feature development within your platform.

With the app store approach, much of the engineering cost goes into shaping the marketplace itself. The underlying architecture determines how much control over your product you give up, and in which directions the market can extend your product's functionality.

Atlassian, one of Gitlab's competitors, takes this approach, with some success. But Gitlab shows no interest in following their lead—there is no app store to be found anywhere in Gitlab's product.

R+D spending spree

A third way to spend money to broaden your product's capabilities is perhaps the most obvious—hire lots of engineers to build all the new features in-house. This is usually the most expensive option, but if executed well, companies retain nearly total control over the nature of their expanded product by simply building it all themselves.

After raising a big round of funding like Gitlab did with its IPO, this is what most tech companies would do.

However, Gitlab hasn't really done this, either—over its last three fiscal years, research and development spending has increased at the same rate as general and administrative expenses. Gitlab is hiring more engineers, but at the same rate it's hiring lawyers, accountants, executives, and HR associates.

That's not an R+D spending spree, that's just company-wide growth.

How Gitlab is actually spending its cash

Enterprise sales

Gitlab is taking its rapidly-increasing revenues and billion-dollar balance sheet assets and spending it on enterprise sales efforts. While it has increased its expenses across all categories since the IPO, its sales and marketing expenses have gone up much more dramatically:

Gitlab's business model positions it as a one-stop-shop for software organizations. To make that pitch in the enterprise, Gitlab needs a B2B sales team to rival its competition—and now, it appears, it has hired one.

But if Gitlab's mostly splurging on sales teams, how is it going to actually build all that new functionality?

"Seed then nurture"

Gitlab believes strongly in its open source foundations. This extends to product strategy. Gitlab's handbook instructs its developers to ship barebones, "mildly shameful" features when entering a new space for the first time. In Gitlab's mind, this "seeds" the general direction for product development to go in the open source community mind space.

From there, Gitlab sees its role as caretaker, "nurturing" feature development forward as open source developer interest and product traction dictates. In theory, this is Gitlab's cheat code—it hopes to get some parts of its SPOG built for free.

Frankly, in the long term, this seems far-fetched. By Gitlab's own metrics, internally developed merge requests vastly outnumber community contributions. Gitlab may continue to court open source, but if it wants its SPOG to get built, it will pay for it eventually.

Engineering budgets aside, Gitlab's business model seems to be working. It continues to peel away enterprise market share from GitHub. In StackOverflow's 2022 developer survey, Gitlab was already more common in the workplace than BitBucket, Atlassian's long-established entry in the version control category.

However, Gitlab owes its current success to its DevOps Platform. While Gitlab may dream of expanding into monitoring, project planning, or security scanning, these features are not why customers choose Gitlab today. Gitlab's performance with the excellent, more narrowly-defined product offering it has today alludes to the biggest obstacle it will face on the road ahead.

The desolation of SPOG

There is a second, more fundamental trade-off embedded in Gitlab's business plan—the concept of the SPOG itself. SPOGs are hard. Everyone wants a single pane of glass, but everyone wants to see different things when they look through the window.

Point solutions thrive because they solve specific problems for specific users better than anything else available. No one wants to rely on a dozen SaaS apps strung together with SAML authentication and Python for their workflow. But tech companies have lots of employees, and different employees have very different needs. In software, one size does not fit all.

DataDog is a whole other company, much bigger than Gitlab. Can Gitlab compete with them while keeping its original product intact? Will Gitlab's project planning functionality really ever be able to compete with Jira in project managers' hearts? Can you really rebuild an entire industry in Ruby and come out selling a truly superior product on the other end?

Ultimately, when building its SPOG, Gitlab's biggest challenge will not be its competition or engineering costs, but rather, the same existential challenge any fledgling startup faces: do customers really want to buy this product?