What Is Single-Player Mode?

By Brian Tr · Updated Oct 6, 2026

A network product has a built-in problem: it's only useful once other people are on it. A marketplace with no buyers is useless to sellers, and a social app with no friends is useless to the first user. Single-player mode is one of the oldest answers to that problem. You build the product so that it delivers real value to one person, on their own, before any network exists. The network gets added on top of a user base the tool already collected.

This article defines the idea, traces where the term comes from, walks through the examples that can be checked against primary sources, and then spends most of its time on the parts that get glossed over: the hard transition from tool user to network participant, and the cases where the approach doesn't fit. It's a deeper look at one of the fixes listed in the chicken-and-egg problem hub, where it appears as "give one side standalone value."

The definition

Single-player mode means a product that works for a single user without anyone else being present. The user gets the benefit from the product alone: storing something, organizing something, running their business, editing a photo. Multiplayer mode is the part that needs other people: sharing, discovering, transacting, being found.

A network product with a single-player mode has two kinds of value:

• Standalone value. What one user gets with an empty network. It doesn't grow when more people join.
• Network value. What a user gets because others are present. It grows with participation, and it's the source of the defensibility described in network effects.

The strategy is to sequence them. Standalone value is the reason to sign up on day one. Network value is the reason to stay, and the reason a competitor can't copy the product by copying the tool.

Where the term comes from

The phrase is borrowed from video games. In a June 2010 post, "Designing products for single and multiplayer modes", Chris Dixon credits Zach Klein with the terminology and adopts it to describe product design. His observation is that products which later developed strong network effects often got their first traction from a standalone use. He lists examples such as Flickr (private photo storage) and Foursquare (personal tracking of restaurants), and treats Skype and Facebook as pure multiplayer products. He also says the framing helps because it reminds designers that people can switch between the two modes from moment to moment, and because game designers already know a lot about building both.

Dixon sharpened the argument in a January 2015 essay, "Come for the tool, stay for the network". The essay describes the pattern: attract users with a single-player tool, then convert them into participants in a network. He uses two examples. Delicious paired cloud bookmark storage (the tool) with a tagging system for finding shared links (the network). Instagram attracted early users with its photo filters, let them post to Facebook and Twitter, and over time its own network became the place people preferred to share. His shorthand is that single-player tools are kindling.

The same essay includes a counterpoint that's easy to forget. Dixon acknowledges that Facebook and Twitter started a network from scratch without a tool, and calls that approach very hard. So the claim isn't that single-player mode is required. It's that it's a way to avoid the hardest version of the cold start.

One caution on attribution. Andrew Chen's work on the cold start problem is the standard reference for how networks get started, and the hub article uses his ideas of the atomic network and the hard side. But the single-player and multiplayer vocabulary itself traces to Klein and Dixon, so that's where to read the original arguments.

Why it helps a marketplace specifically

For a marketplace the problem is sharper than for a social app. A social app needs many users of one type. A marketplace needs two types, and each is the product for the other. That's the coordination failure described in two-sided markets.

Single-player mode breaks the dependency by giving one side a reason to join that doesn't involve the other side. In practice that's nearly always the supply side, because suppliers are professionals with workflows, and workflows can be improved by software. Buyers rarely have a standalone reason to visit an empty marketplace. If you're deciding which side to chase first, supply-first vs demand-first covers the decision, and the tools-first channel appears in the supply acquisition taxonomy as one option among eight.

The best-documented example: OpenTable

OpenTable's own SEC filings describe the pattern in plain business language. Its 2009 S-1 registration statement says the company provides an Electronic Reservation Book (ERB) that computerizes the restaurant's host stand. It's a combination of proprietary software and computer hardware that replaces the pen-and-paper reservation book, covering reservation management, table management, guest recognition, and email marketing. The filing also says the ERBs at restaurant customers connect through the internet to form an online network of reservation books, and that the ERB takes online reservations directly from the OpenTable website.

That's the structure of single-player mode. The tool is useful to a restaurant as a reservation book. The network is the part that sends diners. The filing's own description of the network effect is that the value of the network grows as participation among restaurants and diners grows.

Two details from the filings matter for anyone copying the model.

First, the tool wasn't free. Restaurants pay a one-time installation fee, a monthly subscription fee for the software and hardware, and a fee for each guest seated through online reservations. So the tool had to justify itself as a business purchase, and the marketplace fee came on top. This is a long way from a free app.

Second, the scale at which the network existed was small relative to what we think of today. The S-1 reports approximately 10,000 restaurant customers as of December 31, 2008, and approximately 11,000 as of June 30, 2009. These are restaurants, not diners, and that's the point: the supply side was a base of paying customers using a tool.

The same pattern shows up in the practitioner record. In the supply-side interviews collected by Lenny Rachitsky, an early OpenTable employee describes hiring a direct sales force that knocked on doors carrying the software and demoing it. It is one insider's recollection rather than a primary document, but it fits what the filing describes. The tool is what the salesperson sells.

Other examples worth knowing

The examples from Dixon's essays are consumer networks rather than marketplaces, but the mechanism transfers.

• Delicious. A person could store bookmarks in the cloud for themselves. The tagging system turned individual collections into a shared index. Nobody needed to wait for friends to join.
• Instagram. A filter made a photo look better on its own. Sharing came second. Because posts could go out to Facebook and Twitter, the user wasn't dependent on Instagram's network to get any value.
• Flickr and Foursquare. In Dixon's 2010 post, these illustrate that photo storage and personal restaurant tracking were useful before a social graph existed.

Each of these let a user get value alone and let the product borrow the reach of a larger network at the start. For a marketplace, the borrowed reach would be the supplier's existing customers or a public channel. That idea connects to the "borrow an existing audience" family in the hub article.

Single-player value versus network value

The table sorts the verified examples by what the user got alone and what they got from the network. The "network value" column describes the product's own claims or Dixon's descriptions, not measured effects.

Facebook is in the table on purpose. It shows the other end of the spectrum, the pure multiplayer product, which is why its cold start had to be solved differently.

The transition problem

Getting someone to use a tool is one problem. Getting them to take part in a network is a different one, and most single-player strategies fail here rather than at the start.

The problem has a few parts.

The tool user and the network participant want different things. A restaurant that adopts a reservation book wants fewer no-shows and a tidier host stand. It wasn't looking for more diners, and it may not care about the online channel. You have to give it a reason to switch the network on: a visible benefit, a default setting, or a fee structure where it only pays when the network delivers. The OpenTable filing's per-seated-diner fee is an example of the last one, because the marketplace charge only appears when the marketplace works.

The network can be an afterthought. If the tool is good enough on its own, users have no reason to try the network features. The tool then becomes the product, and the network is dead weight in the interface. Make the network visible inside the tool, so using the tool shows users what they could get from joining.

Network access must come with the tool, not after a separate sign-up. Instagram's early design let users post to other networks while building its own. The lesson is to make the first network action a small step inside something the user already does.

Tool users may be the wrong network participants. The restaurants that buy software aren't a random sample of restaurants. If your tool attracts the kind of supplier that diners don't want, you've built a supply base that's hard to sell. This ties to the quality questions in marketplace supply quality.

A related idea is covered in in-product growth loops: the best transitions are loops, where using the tool produces something that brings in the next user.

The risks

Single-player mode isn't free. These are the failure modes to plan for.

1. The tool succeeds and the network never forms. You end up with a software business. That might be a fine business, but it isn't the marketplace you set out to build, and its economics, sales cycle, and competitors differ.
2. You compete with specialist software vendors. A reservation book competes with every other reservation tool. If your tool is only a loss-leader for the network, dedicated vendors will outbuild you on features. The tool has to be good enough that a user would pick it without the network.
3. Tool users never want the network. Some suppliers like being private. A business that uses your scheduling tool because it wants to manage its existing customers may refuse to be listed in a directory that sends it new, unknown ones.
4. Build cost and time. A tool is a second product. It means engineering, support, and often hardware or installation, as the OpenTable filing shows with its onsite installation and training. That's a heavy price before the marketplace has earned anything.
5. The users you collect aren't dense enough. A thousand tools in a thousand cities don't make a local marketplace. Single-player mode solves the cold start of having any users; it doesn't by itself solve the density needed for matches. Pair it with the narrowing logic from the hub article.

When it fits a marketplace, and when it doesn't

The pattern across these: single-player mode works when the user has a job to do that exists before the network does. It fails when the only job is "get found by buyers," because that job is the network. The question to ask is blunt: if no buyer ever showed up, would this supplier still pay for the product? If the answer is no, you don't have a single-player mode. You have a signup form.

B2B marketplaces fit this test more often than consumer ones, and vertical ones more often than horizontal ones, because a vertical supplier's workflow is specific enough to build for. The horizontal vs vertical comparison goes into why.

A short design checklist

1. Name the supplier's job to be done that exists without buyers.
2. Make the tool good enough that it would sell without the network.
3. Decide the exact moment the user first touches the network, and make it one click.
4. Charge for the network in a way that tracks the value it delivers.
5. Measure how many tool users turn the network on, not how many adopt the tool.

Key Facts: Single-Player Mode

• The single-player and multiplayer terminology is credited by Chris Dixon to Zach Klein in his June 12, 2010 post, which names Flickr and Foursquare as products with standalone use and Skype and Facebook as pure multiplayer.
• Dixon's January 31, 2015 essay describes the pattern of attracting users with a single-player tool and then building the network, with Delicious and Instagram as examples, and calls starting a network from scratch very hard.
• OpenTable's 2009 S-1 reports approximately 11,000 restaurant customers as of June 30, 2009, who pay an installation fee, a monthly subscription fee, and a fee for each guest seated through online reservations.
• The earlier OpenTable S-1 reports approximately 10,000 restaurant customers as of December 31, 2008.
• The OpenTable filing states that the value of its network grows as participation among restaurants and diners grows.

Related Reading

• The Chicken-and-Egg Problem in Marketplaces
• Acquiring Supply for a Marketplace
• Supply-First vs Demand-First
• B2B vs B2C Marketplaces
• Two-Sided Markets
• Network Effects
• In-Product Growth Loops
• Acquiring Buyers for a Marketplace
• Referral Loops in Marketplaces