As I consider the companies that provide software stack solutions for long term investment, I generally look at several criteria to influence my stock selection decisions. These might surprise you, as none are traditional financial metrics. I do consider financial metrics in making final selections, but focus more time on analyzing the company’s products, market opportunity, team and strategy.

Some traditional stock analysts would consider this approach to be backwards. They may start with a set of financial indicators (like P/E, P/S, ROE, etc.), establish ranges for these and then filter out the majority of companies. This approach may work in more mature industries. However, in the evolving software stack space, I think that qualities more closely associated with the company’s product offerings, competitive positioning, total addressable market, developer evangelism and leadership are predictors of long term success. These forces will ultimately drive financial metrics (assuming an experienced CFO is in place) and translate into stock price growth over the long term.

Developer Mindshare

My base thesis is that developers and technical users are increasingly influencing purchase decisions for software solutions. Before the emergence of open API’s and self-service SaaS solutions (let’s say circa 2005), software package purchase decisions were necessarily driven top-down. I say “necessarily” because there was no easy way to “try out” a solution before committing spend. Software vendors would target the CIO/CTO/VPE to present their solution through a traditional sales process. These individuals were the gatekeepers and often had no way to validate the likelihood of solution fit beyond what was promised in a slide deck and curated customer checks.

After 2005, software solution providers began to emerge that could deliver software stack components and services through an API integration. Account sign-up and service provisioning became automated and usage was metered in granular increments. The first examples of this were the hosting cloud providers (AWS, Rackspace, etc.). Soon, this approach expanded to other core services, like messaging (Twilio), email (Sendgrid) and payments (Stripe).

Fast forward to today. Developers (and even hands-on engineering leaders) can evaluate a considered software solution through a free download or programmatic API interface. Accounts are provisioned automatically with short registration and nominal credit card charge. These individuals can quickly try out the service to build a prototype that addresses a business opportunity. They might even test their solution with a slice of customers, as automated A/B testing capabilities have matured. This new approach results in much faster application development iterations and better customer engagement.

Because of this shift, those software companies with a go-to-market strategy that is developer-focused will grow their adoption and share. They will win more deals at a lower cost. Winning deals is easier because a working prototype demo’ed by the developer is more believable than a Powerpoint. Sales costs are lower because usage inquiries and expansion are inbound versus requiring sales outreach.

Rapidly growing software providers still reference this bottoms up motion today. At a recent analyst event, the Datadog CEO said they typically start an engagement through a developer-led trial and then work up the organization structure. The CTO is often last to be contacted. The same process applies to other developer-centric sales motions – Twilio, Fastly, Elastic, MongoDB, etc. all drive appeal with developers first.

Developer evangelism is accomplished by making the workings of the software platform transparent. Documentation is abundant and easy to find. Most functionality can be accessed through open, programmable APIs. The software provider has dedicated staff towards developer support, actively writing blogs and running developer events. The provider should also maintain an active, open GitHub repo with multiple projects containing starter code, shared resources and open source contributions.

If I am considering a company for investment and I can’t easily find these elements on their web site, then I pass. It doesn’t matter how strong other aspects of the investment thesis seem. Developers can sniff out bad tech quickly and are usually involved in discussions with their management about vendor selection. A software company can quickly lose market share if developers think their offering is obfuscated or technically weak.

The most important measure of user adoption for a software stack company is its ability to expand usage within its established customer base. This usage growth is represented as the Dollar Based Net Expansion Rate (DBNER). This rate is calculated as the percentage growth in spend from existing customers over a 12 month period. I like to see software stack companies with a DBNER over 120%. This means that existing customers will spend 20% more each year on the company’s offerings and becomes a powerful force in driving recurring revenue growth.

Questions to consider when evaluating developer mindshare:

  • Has the company extended its software product offerings by exposing the underlying APIs and platform services for developers to consume?
  • Does the company actively target developers for its marketing efforts? If it holds conferences, are they focused on building versus watching?
  • Is it easy to evaluate the software solution in a self-service manner, without talking to a salesperson first?
  • Is detailed documentation publicly available online about API’s and service usage? Are there code samples or starter kits in GitHub?
  • Are the software solutions being taught as part of developer training programs? Bootcamps and university programs come to mind here.
  • Does the software stack company achieve a high DBNER with existing customers?

Leadership in a Large Addressable Market

I think this point goes without saying, but it is important to keep in mind. Ideal investments are for those companies which offer solutions that address large (and more critical) segments of the software stack. Examples of large markets are services like data storage and processing, machine learning and analytics, payments, messaging, application performance monitoring (APM), customer service, workforce automation, etc. Addressing a major segment of the software stack implies a large market opportunity, which in turn, ensures sufficient revenue growth will be available for the long term. If growth will saturate the market size in just a couple of years, then the long-term horizon for an investment is less attractive.

I like to see a total addressable market larger than $10 billion annually. Ideal investments are for companies that provide solutions for a very large market, have only a few percent of share currently and are rapidly disrupting incumbent solutions or pursuing greenfield opportunities.

A further extension to addressing a large market is that the market is still growing. This means that the customer experiences being brought to market using the company’s building blocks are continuing to evolve and expand into new use cases. An example of this is in machine learning and data processing. New use cases emerge continuously that rely on taking a large body of data and deriving useful insights from it. We can think of examples that surface in the apps we use every day – product recommendations (Amazon), cost optimizations (Kayak), predicting outcomes (Waze), etc.

Finally, having a leadership position amongst the companies that offer solutions in the large addressable market is important. This is where we consider competitive position. If the market is greenfield and growing rapidly, the safest bet is to select the leader in a space, usually defined by revenue / market share. If a market is more mature, we look for a company that is rapidly growing their share and disrupting incumbents.

An example of the former is CPaaS and Twilio. Twilio is the largest provider of programmable messaging, voice, video and email solutions. The market for these solutions is significant and growing (estimates of 40-50% CAGR from 2018 to 2023). An example of the latter is MongoDB (MDB), growing rapidly in the data storage space (huge TAM) and disrupting incumbents who have the largest existing market share (Oracle).

Questions to consider when evaluating addressable market:

  • How large (total annual sales) is the market for the software offering that the company provides? What percentage of that market does the company already address through existing revenue streams?
  • Is the addressable market continuing to grow rapidly (more than 10% a year)? IDC, Gartner and other sources provide estimates of market size and growth rates. Is it obvious to you that new use cases for software applications dependent on the software stack solution will continue to rapidly emerge?
  • Who are the competitors in the market space? Are there offline or semi-automated processes that address the need sufficiently? Is the company well-positioned against competitors or to disrupt incumbents?

Product Development Velocity

Software stack companies will continue to extend their growth by launching meaningful new product offerings frequently. These should represent ambitious additions to the product offering with the goal to capture more share of the addressable market or even expand the market itself. These should not represent uninspired extensions to the same offering that are simply repackaged. In software development organizations, this pace of development is often termed as “velocity”.

To measure this, I like to see evidence of rapid development cycles and frequent product releases. The rapid development and release cycles are highlighted on earnings calls, in press releases and industry news. Another way to gauge software engineering activity is to look for activity in public code repositories (contribution to open source or other), product/engineering team blogs and participation of leadership in conferences/podcasts/publishing.

The best cases are those in which new product releases address adjacent segments of the software offering. An example is in data storage, if we look at MongoDB’s (MDB) evolution. They started by offering a core database initially. Then, they expanded the core offering to provide a search capability (albeit full text for now). Traditionally, search services are delivered from a separate data store, structured as a replicated reverse index. MongoDB is further adding capabilities for big data processing, positioning their data clusters as a facade over data lakes.

An example of a rapid release cycle is Datadog (DDOG). In a year’s period from 2018 to 2019, they launched monetized solutions for Synthetics, RUM, Network monitoring and a serverless solution, as well as a Security product in beta. This pace of product development is breath-taking, doubling the number of paid offerings in that year. It is hard to imagine that competitors will catch up with them.

Questions to consider when evaluating product development velocity:

  • How rapidly is the company launching new product features or offerings?
  • Are these ambitious new offerings or merely extensions to the existing product set?
  • Do the new product offerings provide a solution to an adjacent software stack component, which would result in an increase of the total addressable market for the company?

Competitive Moat

Competitive moat is a loosely defined term. At its core, though, it represents the ability of a company to maintain advantages over its competitors that preserve its market share. For software companies, I think this translates into the factors that allow a company to keep its existing customers and keep winning new ones. I think there are several factors that can contribute to a company’s competitive moat that investors should consider as they evaluate a software company. Any one of these can create a reasonable moat. Having several will guarantee market leadership for the long term.

  • Reproducibility. This measures the ability for a new entrant to reproduce a sufficient product to compete with an incumbent’s offering. The barrier to this can be technical complexity, depth of edge cases or even intellectual property. Dating sites are notoriously reproducible. A small dev team can build a new dating site with basic features in a week or two. On the other hand, difficult technical problems often require large teams to build and years to refine with usage at scale. Some examples:
    • Fastly. Built a serverless edge compute runtime that can cold start in 35 microseconds, 100x faster than competitive solutions.
    • Okta. Delivers an online authentication service for apps that is secured against a myriad of potential user fraud edge cases. This involves creating, storing and comparing billions of device fingerprints and other telemetry data to generate a risk profile for every login attempt.
  • Switching Costs. Once an enterprise customer has rolled out a software provider’s solution, switching costs measure how easily the customer could change to a different provider. If switching costs are low, the competitive barrier is minimal. An example of a low switching cost might be in system monitoring (APM, infrastructure, logging, etc.). Most monitoring solutions involve deploying a data collection agent or code snippet to all devices in an enterprise’s infrastructure. This deployment is usually automated and handled by configuration management. So, switching to another vendor’s agent would be pretty easy. An example of a high switching cost is in data storage, like MongoDB or Elastic. Switching to a different data storage solution would involve rewriting parts of the software application and then relocating the data. This is much more involved and maintains a competitive barrier associated with the inherent inertia.
  • Network Effects. Network effects refer to the benefit that a service realizes by having more usage. A popular service is harder to displace because most users are already on it. Consumer Internet examples are social networks and dating sites. For software companies, network effects make the solution more effective through heavier usage. Network effects can take the form of processing more customer data, having more third party integrations, being deployed to more devices, etc. These create an inherent barrier to entry for an incumbent. Not only do they need to build the solution, but also create sufficient usage and integration points to make it more valuable to users. Some examples:
    • Cloud-based security solutions, like Okta and Crowdstrike. These benefit from having a large volume of customer activity data flowing through their centralized cloud service. By parsing the customer data in aggregate, they can quickly identify anomalous behavior at a single customer and then adjust their response for all customers.
    • Docusign has 350 pre-built integrations with popular business applications and resource management systems. Datadog, Okta, Smartsheet, Slack, Alteryx all have assembled similar sets of hundreds of integrations or data connectors with other relevant tools in their respective ecosystems.

One other factor that investors should consider when analyzing the competitive posture of software stack providers is neutrality. This applies to the independent software companies that are not one of the large cloud vendors (AWS, Azure, GCP). I often hear investors express concern when a cloud vendor launches a similar service that competes with an offering from one of the independent providers. The initial reaction is that the cloud vendor will quickly steal share from the independent. However, neutrality and avoiding cloud vendor lock-in is an important consideration for CTO/CIOs as part of their purchase decision. For many software services, they prefer a solution from an independent provider, so that they can maintain presence on multiple cloud vendors and not become beholden to a single one. Some examples where neutrality and specialization is valued is in observability (Datadog), identity (Okta), communications (Twilio) and data storage (MongoDB Atlas).

Technical Founder, Still in Charge

The most progressive and successful software stack companies are started by one or more founders with technical experience. Often, they were software developers themselves and built early working prototypes of the company’s offerings. Ideally, the founders should still be at the company, as the CEO or member of leadership.

This is critical for a couple of reasons. First, it establishes credibility with the user community (to whom the company is selling) and within the company’s own internal engineering organization. This is critical to engender trust, confidence and ultimately talent retention.

Second, the founder intimately understands the problems being addressed by their company’s solutions. They don’t have to rely on a product manager to explain or prioritize the needs of the user community to whom they sell. This allows meaningful oversight of the product development roadmap and transparency of technical complexity. If the founder thinks they could implement a solution themselves in a few months, it is difficult for the delivery manager to claim it will take a year.

Third, if the founder is still in charge of the company, they have a burning desire to ensure it will continue to be wildly successful. They are personally invested and ego is involved. This implies that the internal organization will be leveraged as much as possible. When challenges arise, a founder leader will work all weekend to find a solution. A non-founder leader might spend part of the weekend figuring out a sufficient excuse. While non-founder leaders can deliver, I think vision and drive are diluted as soon as the founder hands off the reigns.

Examples of technical founders, who are still leading the company: Jeff Lawson at Twilio (TWLO), the co-founders of Datadog (DDOG), the co-founders of Okta and Shay Banon at Elastic (ESTC).

Questions to consider when evaluating the leadership of the company:

  • Is the founder formerly a software developer, or technically oriented?
  • Is one of the founders still running the company (CEO or other significant role)?
  • Are the founders still revered by the internal technology organization (Glassdoor or other reviews)?

Top Talent Influx or Exit

The employees of software stack companies have significant impact on the success of the company. It goes without saying, but attracting and retaining the most talented software engineers, product managers and technical personnel is critical. Top talent is attracted to the best companies, where the perception of personal / financial growth opportunities are the greatest. This becomes self-fulfilling. As the company continues to succeed, it will attract more talent, which drives incremental success. If this flywheel starts to slow down and more talent exits than enters, the company’s growth will slow.

This can be hard to measure, but I advise watching announcements of personnel changes. For a new leadership role or replacement, the incoming employee’s background should be impressive. When you hear leaders of the company speak (conferences, podcasts, etc.), it should be clear that the individual deeply understands and can explain the subject matter. For example, I frequently listen to podcasts about software engineering. Recently, I listened to two different episodes, one from a legacy development framework vendor and another from a rapidly growing database provider. A product manager from each company was being interviewed. The database provider’s product manager was superior in her knowledge of the subject matter, incisiveness and clarity, when compared to that of the legacy development framework vendor’s product manager. I am not surprised that the legacy company is losing market share.

Questions to consider when evaluating the talent flow for a company:

  • Do new hire announcements represent individuals with an impressive, relevant background in the space?
  • When you hear employees of the company speak, are you impressed?
  • Does it appear that talented individuals from your personal network are gravitating towards the company?

Values and Organization

These criteria are soft, but is important to the success of the organization. I think that defining a set of values for the company and reinforcing them in obvious ways provides the organization with clear direction as they prioritize activities. We can refer to this collection of values as culture. Culture is important for a company as the number of employees grows. When the company is a small start-up, the core values of the founder are easy for everyone to see/hear, because the founder is often involved in every major decision.

Once the company pushes past several hundred employees, however, each individual’s direct interaction with the founder will be limited. Therefore, having a codified set of values allows any leader to determine how to prioritize an opportunity, distinguish between competing alternatives or decide where to focus resources.

Questions to consider when evaluating the culture of a company:

  • Are the company’s values clearly defined and written down? Often you can find these on the company’s web site and in other public materials.
  • Does the leadership reference a value when speaking publicly or on conference calls? I love to hear a value reference when a CEO is being interviewed.
  • Are there anecdotes of the company doing something visible to reinforce their values?

As this blog evaluates software stack companies for investment recommendations, I will base my analysis on these characteristics of successful software stack companies.