When a Restaurant Software Company Decides to Stop Being Horizontal

The shape of a horizontal restaurant platform

Most restaurant point-of-sale companies start wide because the early sales pitch requires it. A five-person engineering team building a POS system cannot afford to say no to a bar, a quick-service chain, and a white-tablecloth restaurant in the same month. Revenue is revenue, and the category itself, "restaurant software," reads as a single market from a spreadsheet even though it contains businesses with almost nothing in common operationally.

A quick-service chain needs kiosk ordering, kitchen display routing measured in seconds, and menu modifiers that support combo logic. A bar needs tab management, age verification, pour tracking, and fast re-ordering for regulars. A full-service restaurant needs table management, course timing, split checks, and reservation integration. A single product trying to serve all three ends up with a settings menu the size of a small country and a roadmap that satisfies no one particularly well.

This is not a hypothetical problem specific to restaurants. It's the same pressure a16z describes in its argument for vertical software over horizontal software: a product built to serve everyone in an industry inevitably gets pulled toward the features that are common across the whole category, which are rarely the features that make any specific segment love the product.

Where the lowest common denominator shows up

The symptom is usually visible in the settings screen before it shows up in the sales numbers. A horizontal restaurant platform accumulates toggles: enable this for bars, hide this for chains, rename this field for fine dining. Each toggle exists because one segment asked for it and the team didn't want to say no. Individually, every toggle is a reasonable decision. Collectively, they turn the product into something that requires a implementation specialist just to configure correctly for a new customer.

Engineering feels this before the business side names it. Feature requests stop mapping cleanly to a single persona. A change that helps quick-service ordering flow risks breaking the fine-dining course-timing logic that depends on the same underlying order object. QA matrices multiply because every release has to be checked against restaurant types that behave in genuinely different ways. The team that once shipped fast now spends real time reasoning about which of six customer profiles a given change might quietly break.

Sales feels it too, just later. A generalized pitch ("we work for any restaurant") sounds like it should be an advantage, but it makes the product hard to describe in one sentence to a buyer who has a specific, narrow problem. A bar owner evaluating three POS vendors will pick the one whose homepage clearly says "built for bars" over the one that says "built for restaurants" and then explains in a demo that yes, it also handles bars.

What forces the decision

The narrowing decision rarely comes from a single dramatic moment. It tends to accumulate from three directions at once.

The first is churn concentrated in one segment. If quick-service customers keep leaving for a competitor with faster kiosk flows, that's a signal the horizontal product's kitchen routing and modifier logic aren't competitive for that use case, even if they're perfectly adequate for full-service restaurants.

The second is roadmap gridlock. When every planning cycle turns into a negotiation over whose segment gets the next quarter of engineering time, and the answer keeps changing based on whoever complained loudest, that's a sign the product no longer has a coherent point of view about who it serves.

The third is sales cost. Horizontal products often need longer sales cycles because every prospect requires a custom demo tailored to their restaurant type, and every deal risks scope creep as the buyer asks for one more feature specific to their operation. A narrower product shortens this because the sales team can point to reference customers who look exactly like the prospect.

The tradeoffs of narrowing

Narrowing is not a free upgrade. It's a trade, and it should be evaluated as one.

The most obvious cost is addressable market. A restaurant POS company that decides to serve only quick-service chains has, by definition, walked away from every bar, café, and fine-dining prospect in its pipeline. If those segments were contributing meaningful revenue, that revenue doesn't disappear gracefully. Existing customers outside the new focus segment either get grandfathered on legacy support (which keeps the lowest-common-denominator problem alive internally) or migrated off, which is its own difficult and sometimes reputation-damaging project.

The benefit is decision speed. A product built for one segment can make roadmap calls based on a coherent model of the customer instead of averaging across four different customer types. "Should we build advanced pour-cost tracking?" is a straightforward yes for a bar-only product and an agonizing prioritization fight for a horizontal one. This is the same dynamic behind why usage-based pricing works cleanly for some SaaS products and badly for others: pricing and roadmap decisions both get easier once you actually know who you're optimizing for, and harder the more customer archetypes you're trying to serve at once.

Sales messaging tightens as a direct result. "Built for bar and nightlife operators" is a sentence a prospect understands in the first five seconds of a call. It also filters the sales pipeline, since a fine-dining prospect will self-select out rather than waste a sales team's time on a deal that would require custom feature work anyway.

There's a quieter benefit too: hiring and onboarding get simpler. Engineers joining a vertical product can learn one domain model deeply instead of holding four restaurant types in their head simultaneously. According to a16z's more recent analysis of vertical SaaS economics, this specialization compounds over time as AI and automation features get layered onto the product, because a narrow, well-understood domain model is far easier to extend intelligently than a generalized one built to avoid offending any single customer type.

How to tell if you're ready

A useful test is to look at the last four roadmap decisions and ask how many of them were shaped by a specific customer type versus averaged across all of them. If most decisions are compromises, the product has probably already drifted into lowest-common-denominator territory without anyone deciding that on purpose.

Another test: pull churn data by segment, if it exists, and see whether one segment is leaving for specialized competitors while others stay. That's a stronger signal than aggregate NPS, which tends to hide segment-specific dissatisfaction inside a mediocre average.

The honest version of this decision requires admitting that some current customers are subsidizing a roadmap that isn't built for them, and some prospects in the pipeline aren't worth chasing anymore. Neither of those is comfortable to say out loud in a sales meeting, but a product that tries to be right for everyone is often quietly wrong for almost all of them.