When Networks Meet SaaS
How startups can combine SaaS and network effects to gain structural advantages
Software-as-a-Service (SaaS) startups are extremely popular with investors for a host of reasons. SaaS startups are extremely scalable because software has zero (or near-zero) marginal costs once developed, i.e. it costs virtually nothing to create another copy. Combining this scalability with subscription-based pricing results in a revenue model with high gross margins and predictable revenue (ignoring AI and data processing heavy models for now). In addition, many B2B SaaS startups are also fairly defensible because they benefit from high switching costs, i.e. those that are a “system of record” become “embedded” in the day-to-day operations of their customers’ businesses which makes it difficult for competitors to displace them.
So, much like network effect-based startups (although not to quite that extent), SaaS models are both scalable and defensible. They become even more attractive when combined with network effects to create greater structural advantages for startups. This does not include businesses like Udemy and ClassPass that simply use subscriptions to monetize marketplaces or content networks. Instead, my focus is on startups that genuinely combine SaaS products with a network or marketplace model. There are two broad ways of doing this:
- Using SaaS to enhance a network effect-based model
- Using network effects to enhance a SaaS model
Let’s take a deeper look at both.
Using SaaS to enhance network effects
This model is also called “come for the tool, stay for the network” and is a classic strategy to solve the “cold start problem” that plagues most network effects-based startups when they start out. However, its benefits extend far beyond solving that narrow problem.
First, lets address “the cold start problem”. Network effects-based startups become more useful as more users are added to the network, but they have zero value without other participants (on day 0). For example, think of OpenTable, the restaurant reservation marketplace. It is useful for consumers as it allows them to discover restaurants and make reservations. Similarly, OpenTable’s marketplace is useful for restaurants because it brings them more customers. But OpenTable had no restaurants or consumers when it began its startup journey. It needed one side of the marketplace to provide value to the other.
OpenTable solved this problem by first building a SaaS-based reservation system that allowed restaurants to manage their own bookings and accept online reservations on their own website. This was a “single player” software tool because it was valuable to restaurants by itself and allowed them to acquire the supply side of the marketplace. Once they gained critical mass on the supply side, they could open the marketplace to the demand side (consumers). This obviously solved their cold start problem, but it had other benefits as well.
Impact on Scalability
In a previous post, I used the Uber as an example to describe the geographic scaling challenges faced by companies with hyperlocal network effects. OpenTable is a tier-2 marketplace (as we defined in the marketplace matrix) and exhibits the same kind of hyperlocal network effects, i.e. the addition of a restaurant on the marketplace is only useful to users looking to book that specific restaurant or one in that location (or city). So when expanding to a new city, OpenTable would not be able to leverage its restaurant base in the previous city to attract users organically. However, the presence of a single player SaaS tool allows it to attract supply (restaurants) in the new location, which can then organically attract demand. So unlike other hyperlocal marketplaces, the scalabilty of SaaS-enabled marketplaces is not limited by the geographic reach of their network effects. As a result, OpenTable went public in 2009 at a valuation-to-funding multiple of ~6X, above the high-end of the 3–5X expected range for a tier-2 marketplace (and was later acquired by Booking Holdings at a much higher valuation).
Impact on Defensibility
Treatwell (previously called Wahanda), is another example of using SaaS to enhance network effects. Treatwell is a marketplace that allows consumers to book appointments at hair & beauty salons. This is a tier-3 marketplace as it is both hyperlocal (consumers and salons need to be in the same location) and has largely commoditized supply (there aren’t many attributes to differentiate each salon). Much like OpenTable, Treatwell bootstrapped supply by using a “single player” appointment scheduling system, before opening up the demand side. And similarly, this solved both the cold start problem and improved geographic scalability.
However, there is another problem we need to take into account here. As we saw in the case of Uber, commoditized supply in tier-3 marketplaces makes them more susceptible to competition and multi-tenanting, i.e. supply and demand side using more than one marketplace. Treatwell’s SaaS-based appointment scheduling tool solved this problem by locking supply in place. As long as salons were using Treatwell’s system, Treatwell’s marketplace could access their appointment calendars exclusively. And locking down one side of the marketplace helped retain the other side of the marketplace as well, thereby solving any defensibility concerns created by commoditized supply. And again, we can see the results in the capital efficiency of its exit. In 2016, Recruit Holdings acquired a majority stake in Treatwell (then called Wahanda) at a valuation-to-funding multiple of ~6X, significantly higher than the high-end of the 1–3X expected range for a tier-3 marketplace.
Using network effects to enhance SaaS
The second approach of combining SaaS and network effects is sometimes conflated with “come for the tool, stay for the network”, but is actually very distinct because “single player” software is not used to bootstrap or strengthen a network. Rather, SaaS is used to tap into a pre-existing (and sometimes offline) network or a secondary developer platform / marketplace is used to extend the use cases of the core SaaS product.
SaaS for network management and collaboration
The first variant of this approach is using a SaaS tool to manage and/or interact with a specific network. Carta is a terrific example of this model. Carta’s first product was a cap table software that connected startups to their shareholders. Previously, startups had to manually update cap table spreadsheets every time shares were issued or sold. Carta automated this process, improving cap table visibility for startups and improving portfolio visibility for startup investors/employees. This is simple enough, but investors and employees can also have holdings in multiple startups and this is where the network effects kick in.
When Carta signs a startup customer, that customer brings over their pool of shareholders (investors and employees). Improved visibility of their holdings is certainly useful for them, but it is even more useful if they can view all of their holdings (across multiple startups) in the same interface. So these shareholders are organically incentivized to bring other startups to Carta who then bring over their remaining pool of shareholders. This process continues over and over, and as the number of startups on Carta increases, it becomes more useful for all shareholders. This is, in fact, a cross-side network effect (and not simple word-of-mouth) because the product becomes more useful to one side of the network as the other side scales.
I introduced the concept of “network bridges” when explaining the geographic reach of social networks like Facebook. These network bridges act as links that connect disparate network clusters and help the network organically spread across geographic boundaries. Similarly, shareholders who have holdings in multiple startups also act as “network bridges”. The only difference is that these are “cross-side” network bridges, i.e. they act as bridges to organically attract the other side of the network (startups), who then bring in their own cluster of shareholders, and so on. As this network of startups and shareholders hits critical mass, it becomes nearly impossible to displace Carta. When investors have many (or all) of their holdings listed on Carta, they act to prevent portfolio companies from moving to other solutions. This brings the stickiness and scalability of network effects to their SaaS product and, as a result, they are likely to have market leading retention and unit economics as they scale.
If this sounds familiar, its because Github and Slack exhibit very similar dynamics. The only difference is that it is collaborators working with other teams (internal or external to a company) who help grow the network. These collaborators act as “same-side” network bridges, organically attracting new users to the free plan, as well as converting them to paid plans when the intra-company network expands beyond the free tier. In short, their network effects exhibit the bridging pattern seen on just the right side of the visual above.
SaaS + Secondary developer platform or marketplace
The second way of using network effects to enhance SaaS is by building a secondary developer platform or marketplace on top of the core SaaS product. The idea here is that developers can build tools that can be used with the core SaaS product, making it more valuable for customers and increasing switching costs even further. However, this is rarely a viable approach for early stage companies as it requires scale to attract developers. Examples include Salesforce, Atlassian and Xero.
Even Github (developer marketplace) and Carta (marketplace for secondary equity transactions) have layered this model on top of their existing products. This goes to show that SaaS for network management and SaaS with secondary platforms are not mutually exclusive, i.e. they can be layered on top of each other to gain even more structural advantages as companies scale.
SaaS and The Network Matrix
As we have seen so far, there are many benefits to combining SaaS and network effects. Now that we’ve introduced the concept, we can layer it on top of the basic frameworks I explained in my previous posts. In those posts, I classified network effects-based startups on a 2x2 matrix based on the importance of user identity (or supply differentiation) and the presence of network bridges (or cross-border network effects) to aid geographic scaling. Essentially, I view the presence of an integrated SaaS tool as a third axis on these 2x2s.
The applicability of the models I have described in this post varies depending on the type of network or marketplace in question. “Come for the tool, stay for the network” is applicable to any type of marketplace or network across all the tiers listed on the matrix. However, SaaS for network management (outlined in orange on the matrix above) is only possible in cases where user identity is a core component of that network. The reason for this is simple: Customers will only pay for software to manage a network if the identity of its participants matter, i.e. parents, shareholders, collaborators, prospects, etc. Many of these also exhibit network bridging (tier-1) which makes them immensely scalable. However, there are cases, like ClassDojo, where this can be applied to lower potential, hyperlocal networks as well.
These nuances aside, we have seen that SaaS and network effects can be a powerful combination. I am always on the lookout for startups (across all tiers) with the foresight to leverage both to create unfair advantages in their market.