Construye plataforma, no producto: cómo las primitivas compartidas dejan que una persona sola lance varios SaaS

Mi plataforma empezó como un editor de Markdown. Con el tiempo aparecieron un visor web, APIs, un panel interno, licencias, auth y la idea clara de un servicio de publicación. La plataforma no nació de una hoja en blanco: estaba escondida dentro del producto.

Note

La señal no fue "quiero lanzar muchos SaaS". Fue esta: cada producto nuevo reutilizaba el mismo render, la misma identidad, las mismas cuotas y el mismo flujo de entrega.

De producto a plataforma

flowchart TD editor["Editor"] --> render["Core de render"] editor --> auth["Servicio de identidad"] editor --> licensing["Servicio de licencias"] publish["Publicación"] --> render publish --> auth publish --> licensing publish --> deploy["Servicio de deploy + edge"] portal["Portal de cliente"] --> render portal --> auth portal --> licensing portal --> deploy exportApi["API de exports"] --> renderService["Servicio de render"] renderService --> render

La diferencia entre producto y plataforma no es el tamaño del diagrama. Es si las piezas compartidas tienen contrato propio y pueden sostener productos nuevos sin duplicarse.

Señales de que ya tienes plataforma

Código que se repite

El mismo renderer aparece en editor, web y dashboards. No es utilería: es núcleo.

Servicios que todos necesitan

Identidad, licencias, billing, cuotas y deploy vuelven en cada producto.

Coste marginal bajo

El siguiente producto no empieza en cero. Compone primitivas existentes y añade una capa fina.

Inventario de primitivas

Una plataforma útil es pequeña. Si todo es primitiva, nada lo es.

Primitiva	Contrato	Productos que la usan
Core de render	Markdown enriquecido → HTML seguro y decorado	Editor, web, dashboards, publicación, portal
Servicio de identidad	Identidad, sesiones, MFA y scopes	Cualquier producto con login
Servicio de licencias	Planes, cuotas, entitlements y billing	Editor, publicación, portal, API
Servicio de render server-side	Render server-side y exports	Publicación, API de exports, portal
Servicio de publicación	Deploy, temas, dominios y auditoría	Publicación, portal
Capa edge / object storage	Assets y sitios estáticos	Publicación, portal

Important

Una primitiva conoce su dominio. Un producto conoce a la primitiva. Si una primitiva empieza a conocer productos, se convierte en monolito disfrazado.

Productos encima de la misma base

Producto	Qué vende	Qué reusa	Qué añade
Editor	Autoría local-first	Render, identidad, licencia	UI desktop, Git, export local
Publicación	Publicar repos Markdown	Render, identidad, licencia, deploy	Temas, dominios, sites
Portal de cliente	Entrega privada a clientes	Render, identidad, licencia, deploy	Modelo cliente-proyecto
API de exports	PDF/HTML/Word por API	Render, identidad, licencia	Endpoints públicos y cuotas

La plataforma hace que los productos compartan infraestructura, pero no obliga a que compartan experiencia de usuario.

La economía del reuso

El valor aparece cuando baja el coste marginal:

$$
coste_producto_nuevo = capa_especifica + integracion(primitivas)
$$

Si la capa específica es pequeña, una persona puede sostener más de un producto. Si cada idea exige identidad, billing, render y deploy desde cero, no tienes plataforma: tienes una lista de proyectos.

Límites para no crear un monolito

flowchart LR product["Producto"] -->|compone| primitive["Primitiva"] primitive -->|expone contrato| product bad["Producto específico"] -. no debe vivir dentro de .-> primitive primitive -. no debe conocer .-> catalog["Lista de productos"]

Límite	Regla práctica
Identidad	Emite tokens con scopes; no decide pantallas de producto
Licencias	Modela planes y cuotas; no contiene copy comercial
Render	Renderiza Markdown; no sabe si está en editor, publicación o portal
Deploy	Publica bundles; no decide navegación ni contenido

Checklist para aceptar una nueva primitiva

Tiene contrato de entrada y salida claro.
La necesitan al menos dos productos reales o uno crítico y otro en cola.
No contiene copy, layout o casos específicos de un producto.
Puede probarse sin levantar toda la plataforma.
Tiene dueño, README y versión.
Reemplaza duplicación que ya duele, no una hipótesis futura.

Cómo planifico productos nuevos

La primera pregunta ya no es "¿qué hay que construir?". Es:

Tip

¿Qué primitivas existentes reutiliza este producto y qué primitiva nueva obliga a crear?

Respuesta	Decisión
Reusa casi todo y añade una capa fina	Buen candidato
Reusa una parte, pero crea una primitiva valiosa	Puede entrar en roadmap
Requiere una plataforma distinta	No entra aquí
Contamina primitivas existentes con casos raros	Se rechaza o se separa

La parte organizativa

Aunque sea una sola persona, la arquitectura necesita compartimentos claros:

Un repo o paquete por primitiva.
Tests donde vive el contrato.
Productos como consumidores, no como propietarios del core.
Documentación central de decisiones y límites.
Migraciones pequeñas, con paridad visual cuando hay UI.

La disciplina importa más que el número de personas. Si yo mezclo dominios en mi cabeza, el código los mezclará también.

La regla que me llevo

Las plataformas no se construyen desde cero. Se reconocen cuando las mismas primitivas ya sostienen varios productos y empiezas a nombrarlas, versionarlas y proteger sus límites.

Este artículo forma parte de mis notas de plataforma. Si te interesa el tema, sigue el blog o escríbeme.