Cardápio Digital · Order & Pay-at-Table — Análise de Mercado US (Miami + NYC)

00Tese em uma frase

O order+pay-at-table multilíngue-nativo, acessível por design (WCAG) e POS-agnóstico que Miami e NYC precisam para o público internacional — ocupando o quadrante que Toast/Square/SpotOn (lock-in), Sunday (só pagamento) e me&u (não US-native) deixaram vago.

O problema nº 1 do mercado

Integração

Não é a tecnologia de cardápio — é a fragmentação POS/pagamento/fiscal que quebra pedidos.

Restaurantes nos processos ADA

30,5%

Setor mais processado por inacessibilidade web nos EUA. NYC lidera o país.

Onde nasce o moat

Orquestração

Não construir POS/pagamento/tax. Orquestrar SaaS prontos com confiabilidade + experiência.

01O que muda do Brasil para os EUA

A mudança de país não altera só o pitch — altera as portas do hexágono.

Camada	Brasil	EUA (Miami / NYC)	Impacto na arquitetura
Fiscal	NFC-e/NF-e obrigatória (SEFAZ)	Sem e-invoice governamental. O fardo é sales tax (13.000+ jurisdições) + meal tax local	FiscalPort → TaxPort cálculo + retenção + remessa
Pagamento	Mercado Pago + Pix	Stripe Connect — restaurante é o exemplo canônico deles	PaymentPort split + KYC + 1099 grátis
Gorjeta	Marginal	Cultura central — pay-at-table eleva tip ~10%	Tipping vira entidade de domínio
Acessibilidade	Boa prática	Risco de litígio (ADA/WCAG processado, esp. NYC)	Gate legal no design system
Idioma	PT	ES + PT + FR + EN (turismo)	i18n no domínio do menu

02Concorrentes — no que acertam, no que erram

O mercado está partido entre POS fechado (lock-in) e pay-only ride-on-top (sem experiência). O canto superior-direito — order + experiência, POS-agnóstico, US-native — está vago.

quadrantChart title Posicionamento pay/order-at-table (US) x-axis "POS-dependente" --> "POS-agnostico" y-axis "So pagamento" --> "Order + experiencia" quadrant-1 "Ride-on-top de experiencia (ALVO)" quadrant-2 "Ecossistema fechado" quadrant-3 "Pay dentro do POS" quadrant-4 "Pay ride-on-top" Toast: [0.2, 0.75] Square: [0.28, 0.55] SpotOn: [0.22, 0.62] Sunday: [0.82, 0.18] meU: [0.68, 0.82] DoorDash-Tableside: [0.5, 0.55] Alvo: [0.86, 0.80]

Player	Acerta	Erra	Lição
Toast	Ecossistema completo, hardware robusto, +10% receita / +9% ticket	Lock-in hardware proprietário, processamento obrigatório, $69+/mês, vendas agressivas	Não competir com POS — integrar, ser o anti-lock-in
Square	$0/mês, sem app, tipping nativo, fácil	Taxa cresce com volume (2.6%+10¢), customização rasa	Bom como rail, não como diferencial
Sunday	POS-agnóstico 60s p/ pagar, 5× reviews Google, 3.500 clientes, 80M txns/ano	Caro ($49–299/mês + fees), só pagamento — pouca experiência	Prova que "ride-on-top do POS" funciona — sobra a camada de experiência
me&u (ex-Mr Yum)	Order+pay sem app, "For You" com IA, 6.000 venues	Não US-native (AU/global); mais ordering que pay integrado	Personalização vende — ninguém ocupou bem esse espaço em US
SpotOn	#1 G2 Winter 2026, suporte humano real, pricing transparente	Profundidade de feature menor (4.2 vs Square 4.7)	Suporte humano é diferencial real
DoorDash Tableside (ex-Bbot)	Distribuição DoorDash	Tip do Drive → 100% motorista, retido via Stripe; suporte ruim	Alinhamento com o restaurante é posicionamento

03Miami — leitura de mercado

Base de clientes

LatAm + EU

Turismo internacional acelerou a adoção de tech mais rápido que o resto dos EUA.

Copa do Mundo 2026

11/jun–19/jul

Cidade-sede, 1–2M visitantes. ⚠️ Começa em 2 dias — validação de tese, não janela de lançamento.

Multilíngue

Table-stakes

ES/PT/FR + split payment já são esperados, não upgrade.

Contra-tendência crucial: restaurantes de alto padrão em Miami estão voltando ao menu impresso — diners preferem. Isso redefine o produto: o valor não é "QR substitui o cardápio", é ordering + pagamento + personalização. O menu impresso e seu produto coexistem. Não venda "QR menu" — venda scan-to-pay + reorder + idioma do turista.

04Nova York — o mercado mais regulado e litigioso

NYC muda a prioridade nº 1 da engenharia: acessibilidade deixa de ser feature e vira blindagem jurídica.

Processos ADA web — ranking

#1 do país

31,6% dos casos federais (1º sem. 2025). FL 24,2% · CA 18,9%.

Setor mais atacado

Restaurantes

30,49% dos processos. Menus e sistemas de pedido online são o alvo clássico.

Volume 2025

5.100+

Processos federais de acessibilidade web (+37% a/a). Pro se com IA em alta.

Por que NYC é tão perigosa

Três camadas de lei sobrepostas: ADA Title III (federal) + NY State Human Rights Law + NYC Human Rights Law — uma página inacessível pode disparar reivindicações sob as três ao mesmo tempo.
Precedente pró-autor: tribunais de NY permitem ação sem o autor provar que tentou usar o serviço.
Spillover de 2026: deadline ADA Title II (24/abr/2026) cimenta WCAG 2.1 AA como padrão de fato também no setor privado.
Widgets não salvam: 22,6% dos processos de 2025 atingiram sites que já tinham widget de acessibilidade. accessiBe pagou US$ 1M à FTC por alegação enganosa. Acessibilidade tem que ser no código, não overlay

6 falhas = 96% de todos os processos WCAG. Resolver isso no design system elimina quase todo o risco:

Baixo contraste — 79,1% Alt-text faltando — 55,5% Labels de formulário — 48,2% Links vazios — 45,4% Botões vazios — 29,6% Idioma do doc — 15,8%

Fiscal & trabalhista de NYC (o que o TaxPort/Tipping precisa saber)

Item	Regra NYC 2026	Implicação no produto
Sales tax	8,875% (4% estado + 4,5% cidade + MCTD). Comida preparada é tributada (dine-in, takeout, delivery)	TaxPort precisa de taxabilidade de prepared food por jurisdição
Gorjeta voluntária	Não incide sales tax	Tip fica fora da base tributável no cálculo
Gorjeta obrigatória / service charge	Tributada — exceto se passar no teste de 3 partes: rotulada, destacada e 100% ao funcionário	Domínio precisa distinguir tip × service fee × surcharge
Service fees / surcharges	Legais, mas devem ser divulgados antes do pedido (NYC DCWP). "Surcharge" não inclui imposto	UI precisa expor fees antes do checkout — compliance de transparência
Salário mínimo / tip credit	NYC: $17/h; tip credit $2,85 / cash wage $14,15	Contexto p/ features de pooling/relatório de gorjeta

Nota: "No Tax on Tips" federal (2026) é dedução de imposto de renda, não sales tax — não afeta o checkout.

Fine dining NYC: hospitality-first

58% dos restaurantes usam menu QR e 9 em cada 10 diners escaneiam semanalmente — mas o fine dining de NYC adota o modelo híbrido: tech nos bastidores (alérgenos, proveniência, pagamento, personalização) e serviço humano como diferencial. "Não há substituto para hospitalidade." Forçar QR-only gera pushback. Implicação: ofereça modo garçom + autoatendimento, nunca digital-only.

05Miami × Nova York — dois playbooks

🌴 Miami — wedge: turismo & idioma

Diferencial = multilíngue auto-detectado (ES/PT/FR/EN) + split payment.
Alto padrão volta ao impresso → foque pay + reorder + personalização.
Demanda sazonal de turismo (Copa valida a tese).
Tom: experiência, conveniência internacional.

🗽 NYC — wedge: compliance & hospitalidade

Diferencial = WCAG 2.1 AA por design = blindagem contra litígio (#1 do país).
Transparência de fees pré-pedido (DCWP) embutida na UI.
Fine dining → híbrido hospitality-first, nunca QR-only.
Tom: "acessível e em conformidade, sem virar réu".

Síntese: o mesmo núcleo serve os dois — só mudam as features de borda em destaque. Miami vende idioma+experiência; NYC vende acessibilidade+conformidade. A arquitetura hexagonal permite ativar cada uma por feature flag por restaurante/mercado.

06Aliados vs. Concorrentes

A integração de POS é o moat, não opcional. Sunday provou que "rodar em cima do Toast/Square/Clover" destrava o mercado sem pedir troca de PDV.

flowchart LR subgraph Aliados["ALIADOS — integrar, nao competir"] AL1["Stripe Connect
split + KYC + 1099 + tip nativo"] AL2["DAVO by Avalara
sales tax restaurante POS-driven"] AL3["POS via API
Toast - Square - Clover - Lightspeed"] AL4["Supabase
realtime - auth - storage"] AL5["Review prompt
Google pos-pagamento"] end subgraph Compete["CONCORRENTES — ocupar o gap deles"] CO1["Toast / Square / SpotOn
lock-in"] CO2["Sunday
pay-only"] CO3["me-u
nao US-native"] end YOU["VOCE
order + experiencia
POS-agnostico - multilingue - a11y"] AL1 --> YOU AL2 --> YOU AL3 --> YOU AL4 --> YOU AL5 --> YOU YOU -.ocupa o gap de.-> CO1 YOU -.supera.-> CO2 YOU -.localiza melhor que.-> CO3

Port	Aliado US	Por quê
`PaymentPort`	Stripe Connect	Split é o exemplo canônico deles; tip num único charge (fee menor); pre-auth p/ confirmar na cozinha; KYC + 1099 automáticos
`TaxPort`	DAVO by Avalara (ou Stripe Tax p/ MVP)	Purpose-built p/ restaurante POS-driven: retém diário, declara e remete. Genéricos (Anrok) não cobrem food&bev
`POSPort`	Toast / Square / Clover / Lightspeed APIs	O wedge anti-lock-in. Ride-on-top como Sunday
`RealtimePort`	Supabase (ou Hono próprio)	Pedido → cozinha ao vivo
`LoyaltyPort`	Review prompt + perfil	Sunday faz 5× reviews; me&u faz "For You"

07Arquitetura — Ports & Adapters (versão US)

O núcleo não sabe que existe Stripe ou DAVO. Conhece PaymentPort e TaxPort. Trocar provedor = trocar adapter, zero mudança no domínio. É a defesa direta contra o problema nº 1 do mercado (integração quebrada).

Visão de containers

flowchart TB subgraph Clients["Frontends (web / PWA)"] C1["Cliente PWA
scan, menu, pedido, pay"] C2["KDS Cozinha"] C3["Garcom App
modo garcom"] C4["Admin
cardapio, temas, fees"] end subgraph BFFL["Camada BFF (orquestracao por frontend)"] B1["BFF Cliente"] B2["BFF Operacao"] B3["BFF Admin"] end subgraph CoreL["Nucleo de Dominio (Hexagono, puro)"] D["Order - Menu - Table - Tipping
Pricing - Tax - Theme - Loyalty - i18n"] end subgraph Adp["Adapters (Anti-Corruption Layer)"] A1["PaymentPort"] A2["TaxPort"] A3["POSPort"] A4["RealtimePort"] A5["NotificationPort"] end subgraph Ext["SaaS de terceiros"] S1[("Stripe Connect")] S2[("DAVO / Stripe Tax")] S3[("Toast / Square / Clover")] S4[("Supabase Realtime")] S5[("Push / WhatsApp / e-mail")] end C1-->B1 C2-->B2 C3-->B2 C4-->B3 B1-->D B2-->D B3-->D D-->A1-->S1 D-->A2-->S2 D-->A3-->S3 D-->A4-->S4 D-->A5-->S5

O hexágono

flowchart LR subgraph In["Driving Ports (inbound)"] UI["BFFs
REST / tRPC"] WH["Webhooks
pagamento - tax - POS"] end subgraph Hex["Domain Core (sem I/O, testavel puro)"] UC["Use Cases
CriarPedido - FecharConta
CalcularTaxELancarTip - ResolverTema"] EN["Entities
Order - Money - MenuItem - Tip - Allergen"] end subgraph Out["Driven Ports (outbound)"] P1[["PaymentPort"]] P2[["TaxPort"]] P3[["POSPort"]] P4[["MenuRepoPort"]] P5[["RealtimePort"]] end UI-->UC WH-->UC UC-->EN UC-->P1 UC-->P2 UC-->P3 UC-->P4 UC-->P5 P1-.->MP["StripeConnectAdapter"] P2-.->FN["DavoAdapter / StripeTaxAdapter"] P3-.->SP["Toast/Square/CloverAdapter"] P4-.->PG["PostgresAdapter"] P5-.->SB["SupabaseRTAdapter"]

Fluxo: scan → pedido → cozinha → pay + tip + tax

sequenceDiagram actor Cli as Cliente participant PWA as Cliente PWA participant BFF as BFF Cliente participant Core as Domain Core participant RT as RealtimePort participant KDS as KDS participant Pay as PaymentPort participant ST as Stripe Connect participant Tax as TaxPort Cli->>PWA: scan QR /r/rest/mesa/N (idioma auto) PWA->>BFF: GET sessao + cardapio + tema BFF->>Core: resolveMenu + resolveTheme + i18n Core-->>PWA: cardapio acessivel, na marca, no idioma Cli->>PWA: monta pedido, envia PWA->>BFF: POST /orders BFF->>Core: CriarPedido Core->>RT: order.created RT-->>KDS: push ao vivo Cli->>PWA: fechar conta + tip 18/20/22% PWA->>BFF: POST /checkout Core->>Tax: calcular sales tax (prepared food) Core->>Pay: charge unico (itens+tax+tip, application_fee) Pay->>ST: PaymentIntent (split + KYC) ST-->>Core: webhook aprovado Core-->>PWA: recibo + review prompt Google

Deltas vs. versão Brasil

FiscalPort → TaxPort — calcula sales tax/meal tax por jurisdição e remete via DAVO; o "documento" é só recibo.
Tipping vira entidade de domínio — sugestões pré-calculadas, no mesmo charge Stripe; distingue tip × service fee × surcharge (regra NYC).
PaymentPort = Stripe Connect — application_fee é a comissão; pre-auth → captura na confirmação da cozinha.
POSPort promovido a cidadão de primeira classe — canal de entrada ride-on-top, não "legado opcional".
Contrato a11y = gate legal (risco ADA, crítico em NYC) — sem overlay, acessível no código.
i18n no domínio do menu com auto-detecção do idioma do device — diferencial Miami.

08Ferramentas — velocidade + estrutura

⚡ Velocidade (time-to-market)

Stripe Connect + Stripe Tax — split, KYC, 1099, tax em ~1 linha p/ MVP
Supabase — auth + db + realtime + storage num provider
shadcn/ui + design tokens — UI white-label rápida
Clerk ou Supabase Auth — sessão de mesa e admin

🏗️ Estrutura (arquitetura)

Turborepo — core/ ports/ adapters/ bff-*/ apps/* packages/design-tokens
Contratos de porta tipados + tRPC/OpenAPI entre BFF↔front
Feature flags por restaurante/mercado (Miami vs NYC)
Teste de a11y no CI (axe-core) — bloqueia regressão WCAG

Não construa: POS, rails de pagamento, motor de sales tax, KYC. Construa: a camada de orquestração confiável + experiência multilíngue + design system white-label + acessibilidade. É aí que está o moat e onde os concorrentes falham.

09Síntese de oportunidade

Dor / gap de mercado	Sua jogada arquitetural	Mercado
Integração quebra (tablet graveyard, pedido órfão)	ACL nos adapters + reconciliação idempotente; stream único	US
Lock-in de POS	POS-agnóstico via `POSPort` (Toast/Square/Clover)	US
Só pagamento, sem experiência (Sunday)	Order + reorder + personalização "For You"	US
Litígio ADA (restaurantes = 30,5%, NYC #1)	WCAG 2.1 AA no design tokens + axe no CI; sem overlay	NYC
Turista internacional sem idioma	i18n no domínio, auto-detecção ES/PT/FR/EN	Miami
Transparência de fees (DCWP)	Fees expostos pré-checkout por design	NYC
Fine dining rejeita QR-only	Híbrido: modo garçom + autoatendimento	NYC / premium
Suporte ausente no pico	Observabilidade + self-healing (alinha OTel)	US

10Fontes

Concorrentes & pay-at-table: UpMenu — Toast competitors · eatapp — pay-at-table solutions · SpotOn vs Toast · DoorDash Tableside (Bbot) — tip handling

Miami: Miami Hospitality Authority — tech adoption · Invent — FIFA WC 2026 multilíngue · MiamiCurated — retorno ao menu impresso

NYC — ADA / acessibilidade: Inclusive Web — NY #1 alvo · NK Legal — por que NYC lidera · WCAGsafe — estatísticas 2025–2026 · Accessible.org — previsões 2026 · TestParty — por que widgets falham

NYC — fiscal / trabalhista: NY State — Sales by Restaurants · Kintsugi — NY food tax 2026 · NYC Rules — Restaurant Surcharges · TipHaus — NY tipping laws 2026 · HelpNewYork — NYC sales tax & fees

NYC — tendências fine dining: Modern Restaurant Management — outlook 2026 · QSR Magazine — hospitality-first · EHL Insights — restaurant tech 2026

Pagamento / tax / build-vs-buy: Stripe Connect · Stripe — separate charges & transfers · TaxCloud — sales tax software (DAVO/Anrok) · KitchenHub — ordering software · Lunchbox vs Olo

⚠️ Parte das fontes são blogs de fornecedores (interesse comercial); dados de litígio/fiscal vêm de fontes jurídicas e governamentais. Nada aqui é aconselhamento jurídico — validar compliance com advogado e com NYC DCWP / NY Dept. of Taxation.