Definition #
A manifestation of [Vendor Capture] specifically producing revenue for the vendor by inverting the pricing frame on table-stakes infrastructure — direct ordering, mobile reservation, integrated loyalty, modern payment, owned digital storefront. The market-side complement to [Table-Stakes Refusal]: where [Table-Stakes Refusal] names the operator’s failure to build the baseline that the modern Guest expects, [Table-Stakes Repricing] names the market’s response to that failure. The vendor sells baseline infrastructure as a “foundation layer” or growth product, thereby extracting fees for what the operator’s baseline obligation already requires.
Understanding [Table-Stakes Repricing] requires holding the full triangle in view: the operator’s [Table-Stakes Refusal] creates a vacuum where the baseline should have been built; the market fills the vacuum with [Table-Stakes Repricing]; the operator pays for the vacuum being filled at prices they would not have paid if they had built the baseline in-house. The three terms are structurally linked and typically arrive together in the operator’s operation. Removing the repricing without addressing the underlying refusal simply moves the operator to a new vendor charging similar prices for the same baseline, because the underlying vacuum has not been filled. Addressing the refusal without recognizing the repricing leaves the operator overpaying during the transition, which extends the transition timeline and often prevents its completion.
The term also functions as a specific delivery pattern of [3P Arbitrage] — the vendor holds the mechanics of the operator’s baseline infrastructure, the operator pays a subscription to keep it running, and the delegation of the baseline function compounds one-way. Every quarter the vendor owns the infrastructure is a quarter the operator does not learn to own it, and the switching cost accumulates while internal capacity does not. Where general [3P Arbitrage] applies to any operational function a vendor holds on the operator’s behalf, [Table-Stakes Repricing] names the specific case where the function the vendor is holding is a function the operator should have built as a baseline obligation, and is being sold as growth work rather than as baseline work.
The pricing itself is not the failure — the framing is. When a vendor calls direct ordering a “growth strategy,” the operator hears growth instead of hearing baseline obligation, and the misread funds the vendor’s business model. The vendor is not lying — they are pricing what the operator is willing to buy at the frame the operator is willing to buy it in. The two-way responsibility here is important: the vendor is running a legitimate transactional play on their side, and the operator is failing to recognize baseline obligation as their own responsibility on their side. Fixing the repricing requires the operator to see their own contribution to the mechanism, not to blame the vendor.
Explanation #
The operator develops read capability on [Table-Stakes Repricing] through an arc that runs alongside the operator’s growing awareness of what a modern restaurant operation actually requires as baseline. Because the technology landscape changes every few years, the arc has to run repeatedly — a new baseline emerges, the operator initially treats it as optional or as a growth investment, and the read has to happen again with the new component.
The first encounter is usually the vendor pitch. A vendor arrives with a product — direct ordering, mobile reservations, loyalty integration, or the current generation’s version of baseline infrastructure — and pitches it as a growth strategy. The pitch emphasizes revenue lift, customer acquisition, competitive advantage. The operator hears growth, evaluates against a growth ROI, and either accepts (buying growth) or declines (postponing growth). What the operator does not yet see is that the product is not growth infrastructure — it is baseline infrastructure that the operation increasingly requires simply to remain viable as Guest expectations shift.
The second encounter is when the operator sees the market shift. A competitor adopts the technology and reports operational improvements. A third-party review site or a Guest survey mentions the missing capability. A younger Guest cohort begins expecting the capability by default. The operator now feels behind, and the vendor’s pitch, which was framed as growth, now feels like catch-up. The operator often accepts the vendor’s product at this stage, still under the growth framing, because that is the only framing the market provides.
The third encounter is post-adoption. The operator has the technology in place, is paying the vendor’s subscription, and has not experienced the promised growth. The technology is being used — Guests do order directly, Guests do use the loyalty program, Guests do book through the reservation system — but the operator does not see the growth that justified the purchase. The operator experiences this as vendor underperformance, or as their own execution failure, or as market conditions. The operator does not yet see that the technology was never going to produce growth, because the technology was baseline infrastructure sold with a growth frame. Baseline infrastructure produces baseline function, not growth. The operator’s disappointment is real, but it is disappointment at not receiving something the vendor could never have delivered.
The fourth encounter is external. The operator watches another operator adopt a similar technology and hears them report similar disappointment. The pattern starts to become visible — every operator in the peer network is buying growth technology and reporting operational maintenance, not growth. The operator now begins to suspect that “growth technology” as a market category may be doing different work than its name suggests.
The fifth encounter is the audit of the operator’s own [Vendor Stack]. The operator lists every vendor, every subscription, every platform, and asks a specific question: which of these are actually growth infrastructure, and which are baseline infrastructure that was sold as growth? The answer, for most operators, is that a substantial portion of what they thought was growth spending is actually baseline spending — often 60% or more of their marketing and technology budget is being spent on capabilities that let the operation function at current-market baseline, not on capabilities that expand the operation beyond baseline. This is the stage where the operator can see [Table-Stakes Repricing] clearly for the first time as a distinct mechanism operating across their entire vendor stack, not as a single vendor’s practice.
The sixth encounter is the exit attempt. The operator tries to reduce dependency on the repriced-baseline vendors and discovers the switching costs are structural. The Guest data lives inside the vendor’s platform. The staff have built workflows around the vendor’s interface. The integrations with other vendors — POS, accounting, reservations — assume the current vendor’s presence. Exit requires the operator to either bring the baseline function in-house (which most operators lack the internal capacity to do) or switch to another vendor doing the same repricing at a similar price. Neither path solves the underlying issue of baseline obligation. This is where operators often make peace with the repricing as a permanent operational cost, because the exit paths do not lead somewhere the operator can actually reach with current capacity.
The seventh encounter is the [Table-Stakes Refusal] audit — the operator finally recognizes that the repricing is not just a vendor problem, it is a symptom of the operator’s own historical refusal to treat baseline infrastructure as a baseline obligation the operator should build and own. The operator identifies specific baseline capabilities the operation should have built years earlier — a proper Guest database, direct-ordering capability the operator owns, first-party loyalty logic — and commits to building them in-house on a multi-year timeline, accepting the interim cost of continuing to pay vendors during the transition. This is the stage where the operator has moved from being subject to the repricing to actively unwinding it.
The eighth encounter is post-exit, once the operator has rebuilt baseline capacity in-house across multiple functions. The operator can now identify [Table-Stakes Repricing] in other operators’ vendor stacks quickly, and can teach the read by walking through the vendor list and asking, for each vendor, “is this growth infrastructure or baseline infrastructure sold as growth?” The answer to that question is usually clear within one conversation, and it typically reveals a repricing pattern the other operator has not yet named. This is also the stage where the operator can evaluate new vendor pitches accurately — hearing “growth” language applied to what is actually baseline capability triggers the read immediately, and the operator can price the offering against the baseline framing rather than the growth framing.
On the operation, the repricing shows up in the tech stack budget as a line item labeled “growth technology” or “marketing operations” that on inspection contains payment processing, POS integration, online ordering, and reservations, none of which are growth by any operational definition. On the P&L, it shows up as software subscriptions that grew faster than revenue over a three-year window, because the operator kept adding platforms priced as “growth” that were, in mechanism, replacing baseline capabilities the operator never built. On the floor, it shows up as operational limitations imposed by vendor lock-in — the operator cannot change their reservation policy without a support ticket, cannot alter their online menu without paying for a “custom development” hour, cannot access their own Guest data without a vendor-mediated export.
