Commercial architecture es una cadena, no una pricing page

La mayoría de equipos publica una pricing page y lo llama monetization. Luego añaden Stripe. Luego hardcodean “Pro gets feature X” en tres rutas de API. Luego ops necesita una cuenta complimentary y alguien abre un hotfix. Luego llega la factura del vendor y nadie sabe qué tenant quemó el margen.

Ese patrón es habitual porque el atajo de soft-launch — “pricing + FinOps + growth” — suena completo. Es necesario pero incompleto. Un modelo commercial serio no es un documento, una página o una integración de billing. Es un system of capabilities con owners nombrados, una secuencia clara y un único product catalog como source of truth.

Este artículo es project-agnostic: una commercial architecture portable que cualquier equipo SaaS o multi-tenant puede reutilizar. Misma idea que en architecture de dominio en este blog — boundaries first, enforce at the edge, no inventes una segunda verdad en el payment provider.

• Monetization es una chain: catalog → agreement → provision → entitlements → meter → bill → cash (+ FinOps cost loop).
• One catalog alimenta pricing, admin, entitlements y billing — nunca una segunda lista de plans en el MoR.
• Entitlements ≠ feature flags; deny con un upgrade path claro.
• Ship Encode (catalog + enforce + gates + admin) antes de Charge; legalize antes del primer pago real.
• Cost ≠ revenue — FinOps y pricing son ledgers separados.
• Quédate con el cheat sheet y la lista Start Monday al final.

Los stacks líderes de billing y entitlements (Stripe Billing / Chargebee-class, capas entitlement + meter, práctica FinOps en el lado del coste) tratan la monetization como one governed chain. Marketing puede empezar con una pricing page. Architecture empieza aquí:

Cada flecha es un handoff. Si saltas un eslabón — por ejemplo billing sin entitlements, o entitlements sin catalog — el siguiente equipo inventa su propia verdad. Así acabas con tres listas de plans: una en la web, una en el folklore de admin, una en Stripe.

Matiz: entitlements y metering no son solo left-to-right. Los caps a menudo leen meters (“allow if usage is under the limit”), así que los meters alimentan entitlements, billing y FinOps. Mantén la chain de siete pasos como historia principal; el cap check es un feedback edge, no una excusa para fusionar “entitle + meter + bill” en un solo blob.

También hay un parallel cost loop. Revenue pregunta “¿qué pagaron?” Cost pregunta “¿qué pagamos nosotros por servirles?” Mezclar ambas es cómo los equipos underprice para siempre o cortan features en pánico sin datos.

Los meters alimentan entitlements (caps), invoices (más tarde) y FinOps (siempre). Puedes meter para caps y fair use mucho antes de cobrar una tarjeta. Las flechas discontinuas son feedback: usage informa allow/deny y cost; cost informa packaging.

FinOps es solo un actor — y solo en el lado del coste. La chain falla cuando todo se vuelca en “pricing”, “billing” o “engineering will add a flag”. Nombra a los owners, aunque al principio una persona lleve tres hats.

RevOps alinea sales, marketing y customer success alrededor del revenue lifecycle — quién posee activation, expansion, renewal y señales de churn. Suele importar después de Charge. Al principio suelen ser runbooks de founder + CS, no un equipo dedicado ni una superficie de producto.

Dos caminos, mismo sistema — ledgers distintos:

Pricing / catalog / billing viven en el revenue ledger. FinOps vive en el cost ledger. Ninguno sustituye al otro. Cuando el margin falla, FinOps informa a Product; cuando un tenant supera el limit, Platform enforce y Ops puede override — con audit trail, no un DM de Slack y un deploy olvidado.

Estas rules son la diferencia entre “tenemos pricing” y “tenemos commercial architecture”. Si las saltas, reconstruirás el mismo lío cada seis meses. Bajo cada rule: una strategy que puedes shippear sin esperar al billing suite perfecto.

Plans, SKUs, limits y trial rules viven en una source of truth. Pricing page, admin y billing la leen todos.

Strategy: Pon el catalog en código versionado o una tabla DB pequeña — plan_id, display name, limits, trial days, module defaults. La /pricing pública y el copy i18n importan ese modelo; no redefinen tiers. Cuando llegue billing, crea productos MoR desde los catalog IDs (map 1:1), nunca al revés.

Flags = rollout. Entitlements = verdad commercial + security en request time.

Strategy: Un resolver: tenant → plan + overrides → { modules, caps }. Llámalo desde API middleware o una policy layer compartida en cada path de pago/coste. Reserva flags estilo LaunchDarkly para “¿está live este code path?”, no para “¿este tenant está en Pro?”.

Un fallo de entitlement devuelve un mensaje claro de upgrade / denied, nunca un silent fail.

Strategy: Deny payload estándar: code, limit, current, upgrade_to, cta_url opcional. La UI mapea codes a copy (“Storage full — upgrade to Plus”). Loguea denials con tenant + capability para product/FinOps. Nunca un 403 crudo con body vacío.

Incluso productos seat/subscription hacen metering para caps, fair use y FinOps.

Strategy: Emite usage events en los edges que cuestan dinero (email, storage, AI tokens, maps, outbound sync). Guarda tenant_id, metric, quantity, at. Empieza con events append-only + totales en admin — sin math de invoice todavía. Los caps leen los mismos meters después; billing los ratea después.

Complimentary access, custom caps, extend trial — con audit.

Strategy: Modela overrides como data en el tenant: plan_override, cap_overrides, complimentary_until, notes. Admin UI escribe; cada write añade who / when / what / before / after. El resolver mergea catalog defaults ← overrides. Sin hotfix branches para “dales Plus”.

Invite vs open, monetization mode, cost kill-switches — sin redeploy.

Strategy: Tabla de global settings (o config service): registration_mode (invite / open), monetization_mode (soft_launch / trial_enforced / paid_enforced), kill-switches por capability cara. Enforce en create-tenant y en features costosas. Defaults = soft-launch de hoy; pasar a paid es un settings change, no un release train.

FinOps (lo que pagamos) nunca sustituye Pricing (lo que pagan ellos).

Strategy: Dos vistas: revenue (plan, MRR, invoices) y cost (vendor invoices + usage allocated). Unit economics = cost per tenant vs price per tenant. Cuando el margin se rompe, cambia package/price o kill-switch — no lo “arregles” fingiendo que el cost es una plan feature.

Entity, tax/VAT, MoR vs Connect (o equivalente) como policy escrita antes del billing go-live.

Strategy: Un go-live memo corto: quién vende, quién factura, tratamiento VAT, MoR vs marketplace Connect, cuándo empiezan los books a reconocer revenue. Bloquea checkout de production hasta que exista el memo. Product puede terminar Encode en paralelo; Charge espera al memo, no a un teatro legal perfecto para siempre.

Commercial object (general): a menudo el tenant / account / workspace es el SKU primario. Los seats pueden llegar después. Forzar “per user” como único modelo temprano encierra el packaging en una forma que puede no encajar con value (o cost). Strategy: price y entitle el tenant primero; añade seat SKUs cuando el cost o value por seat esté probado.

No necesitas diez product epics el día uno. Sí necesitas tres layers que sigan distintos en design, aunque el delivery se comprima.

Define es aburrido a propósito: plans y limits versionables. Si /pricing es una tabla hecha a mano que discrepa del runtime, no tienes catalog — tienes marketing.

Define — solution: un módulo Catalog exportado a web, API y (luego) jobs de sync de billing. Snapshot o version ID en cada entitlement resolution para que el audit sepa qué catalog aplicó.

Enforce es donde la verdad commercial encuentra el request path. Resolve plan → modules/caps allowed → allow o deny. Soft-launch puede seguir siendo “pilots get broad access”, pero como override o mode explícito — no como “enforcement doesn’t exist yet”.

Enforce — solution: middleware / policy helper en cada ruta costosa; global growth settings + per-tenant overrides; pilot = complimentary o monetization_mode = soft_launch, no checks ausentes.

Monetize & operate es donde viven money y margin. Viene después de Define + Enforce salvo que la ley fuerce billing primero — y aun así, catalog + entitlements siguen siendo el product SoT.

Monetize — solution: productos MoR clonados desde catalog IDs; webhooks actualizan tenant.plan / paid flags; portal lee el mismo catalog + meters. FinOps empieza como spreadsheet + vendor dashboards; budgets in-app solo cuando existan meters.

Sequence rule: no implementes billing / portal antes de Define + Enforce. La legal / money-flow policy viene antes del billing go-live. Billing no debe inventar una segunda plan list.

After you charge: los subscription webhooks (o equivalente) son el SoT del paid state — actualizan plan / entitlements. El billing provider mapea 1:1 al catalog. Es SoT de si pagaron; no es SoT de lo que un plan significa.

Si la chain es el target, estos atajos la rompen. Cada uno con un recovery move concreto:

Orden de recovery cuando ya tienes un lío:

Extract desde la pricing page y dashboards MoR → wire one resolver → centraliza hard-coded checks → admin overrides → solo entonces confía en webhooks como paid-state SoT.

Architecture es abstracta hasta que ops puede moverse sin engineering.

World-class se siente así: un pilot necesita complimentary Plus treinta días — ops flips a flag, pone expiry, audit log who/why. Sube el vendor cost — alguien togglea un kill-switch en una integración cara sin deploy de viernes noche. Soft-launch cierra — cambian registration_mode y monetization_mode, y create-tenant / upgrade paths siguen al momento.

Si cualquiera de eso sigue pidiendo un hotfix branch, la chain está incompleta. Admin no es un UI nice-to-have; es cómo los overrides se vuelven first-class en lugar de excepciones tribales.

La capacidad es finita. Aun así puedes mantener boundaries aunque combines delivery. El error no es shippear Encode en un milestone — es shippear Encode + Stripe como un blob indiferenciado.

Encode es la barra de soft-launch que aún se ve industry-shaped: one catalog, enforce en el request path, gate growth, ops override con audit. Puede que aún no cobres — y está bien.

Encode — playbook: (1) catalog model + /pricing cableada, (2) entitlement resolver + tests Free vs Paid vs pilot, (3) global registration/monetization settings, (4) admin plan/override/audit UI. Cuatro workstreams en un milestone si hace falta — nunca un blob FR único.

Charge order: legalize → subscribe / renew / cancel → webhook updates plan. Nunca “crea products en el MoR primero y reverse-engineer el catalog después”.

Charge — playbook: go-live memo → clone catalog into MoR → checkout path → webhooks → UX thin “pay / manage”. El portal polished espera a Scale.

Scale es cuando customers ven usage e invoices in-product, los meters se enriquecen y FinOps puede pasar de spreadsheets a alerts. Optional — no es prerequisite para cobrar limpio.

Scale — playbook: deepen meters (admin first) → customer usage + invoices → optional budget alerts ligados a kill-switches.

Parallel ops track (not product): review mensual de vendor bills, disciplina de margin en el first customer, y playbooks RevOps pueden vivir como runbooks mientras Encode ships. No esperes a un FinOps UI in-app para practicar cost hygiene — y no confundas esos rituales con la commercial chain.

Úsalo como barra, no como vanity checklist. La commercial architecture es “real” cuando:

Haz screenshot. Es el artículo entero en una card.

Una pricing page vende la historia. Commercial architecture la hace enforceable.

Cinco moves para empezar Encode sin esperar a Stripe:

Cuando esas cinco son verdad, tienes el skeleton de Encode. Charge es una decisión posterior — no un sustituto de este trabajo.

Una pricing page vende la historia. Stripe (o cualquier MoR) mueve el dinero. Ninguno es la architecture.

Commercial architecture es la chain — catalog → agreement → provision → entitlements → meter → bill → cash — más el cost loop, más los actors que poseen cada eslabón. Construye Define y Enforce antes de celebrar Charge. Mantén one catalog. Trata overrides y growth gates como product, no como folklore.

Esa forma funciona en cualquier project. Los nombres de plans y providers cambiarán. La chain no debería.