Desarrollar un marketplace B2B para una distribuidora regional toma entre 10 y 14 semanas si se hace módulo por módulo desde arquitectura validada y datos reales. El caso de referencia de Catalizadora es una plataforma multi tenant para 100 franquicias de una distribuidora con presencia en Centroamérica y Estados Unidos, entregada en 12 semanas con Next.js, FastAPI, Supabase Pro y Stripe Connect. 249 issues en Linear, 886 story points, código 100 por ciento propiedad del cliente.
No se trata de adaptar un SaaS genérico, ni de pagar licencia por usuario por sucursal. Se trata de construir el sistema que la operación necesita, con aislamiento por tenant y pasarelas que respetan la realidad fiscal de cada país.
Por qué una distribuidora regional necesita marketplace propio, no SaaS forzado
Una distribuidora regional con franquicias o sucursales en varios países vive un problema invisible: cada sucursal opera con stock, precios y clientes distintos, pero la matriz quiere visibilidad consolidada. Los SaaS B2B globales fuerzan un modelo único de pricing y descuento que no respeta la operación real.
El caso real de Catalizadora arranca con 239 países en catálogo, 446 oficinas, 2.7 millones de clientes y contactos, y un histórico de 98 millones de filas que nunca habían sido normalizadas. Cualquier SaaS habría empujado al cliente a empezar de cero. La salida fue construir el marketplace desde la operación existente, no encima de ella.
Arquitectura recomendada para un marketplace B2B multi tenant
El stack que entrega resultado en 12 semanas para una distribuidora regional con muchas sucursales es directo y propietario:
- Frontend Next.js con SSR y next intl para múltiples idiomas
- Backend FastAPI en Python o NestJS en TypeScript, dependiendo del equipo interno
- PostgreSQL gestionado en Supabase Pro con Row Level Security por oficina y rol
- 7 roles RBAC mínimo: admin global, regional, dueño de franquicia, admin de franquicia, gerente, usuario operativo y auditor
- Stripe Connect Standard para pagos pass through, una cuenta por franquicia
- Mapbox para geocoding y catchment area por sucursal
- Sentry para observabilidad
- Anthropic Claude para traducción batch del catálogo a múltiples idiomas
La clave es el aislamiento por tenant en la capa de datos. Las políticas RLS leen el oficina id del JWT custom claim y filtran cada query. Nadie ve datos de otra franquicia salvo los roles globales explícitamente autorizados.
Módulos típicos de un marketplace B2B para distribuidora
| Módulo | Función | Semana de entrega |
|---|---|---|
| Catálogo central | Productos con SKU, foto, precio base, variantes | 3 a 4 |
| Pricing por franquicia | Precio de venta con override sobre base | 4 a 5 |
| Cross sell intelligence | Sugerencias de venta cruzada por país y oficina | 6 a 7 |
| Carrito y checkout B2B | Cotizaciones, órdenes, aprobaciones | 7 a 8 |
| Pagos Stripe Connect | Pass through sin margen del integrador | 8 a 9 |
| Reportería ejecutiva | 28 KPIs en código TypeScript, narrativa IA | 9 a 10 |
| Audit trail SHA 256 | Hash chain inmutable de toda transacción | 9 a 10 |
| Onboarding automatizado | Self service por franquicia con welcome flow | 10 a 11 |
Cada módulo nace de un hallazgo de datos, no de una hipótesis de producto. Eso es lo que diferencia un marketplace que se usa de uno que se abandona.
El caso real: distribuidora con 100 franquicias en Centroamérica y Estados Unidos
Caso de referencia: distribuidora regional con 100 franquicias activas, 204 oficinas reales con al menos un empleado y un cliente activo, y 9,931 empleados de seed inicial. El contrato fue de 26,000 USD fijos por 12 semanas. Sin sobrecostos, sin órdenes de cambio.
- 3.6 millones de filas migradas a Supabase en 48 horas
- 197 tablas snapshot, 825 silver views, 75 gold materialized views
- 73 tablas Gold finales normalizadas en arquitectura Bronze, Silver, Gold
- 28 KPIs hardcoded en JavaScript, narrativa IA sólo sobre datos verificados
- 57 RLS policies y 17 roles RBAC asignados
- Wave model de rollout: 3 olas de testing más una ola de go live el 26 de julio
Los KPIs viven en código. La narrativa la genera la IA encima de números calculados en TypeScript. Cero hallucinations en métricas.
Cómo evitar el bloqueo de SaaS típico en distribución
Tres principios que se aplican desde el día uno:
- Stripe Connect Standard, no Stripe Connect Express. Cada franquicia es titular de su cuenta y de su relación fiscal con la pasarela.
- Catálogo central con override por franquicia. El precio base vive en la matriz, el descuento o sobre precio vive en la franquicia.
- Audit trail SHA 256 append only. Cada acción queda registrada con hash encadenado, verificable por la función
audit.verify_chain_integrity(). Cumple compliance sin contratar herramienta externa.
Cuando los datos se unifican, los problemas se anuncian solos. Inventario con cantidades negativas, esquemas de pago paralelos, servicios prestados que nunca se cobraron. Todo emerge cuando el 100 por ciento de la operación converge en el data lake.
Próximos pasos
Si diriges una distribuidora regional con varias franquicias o sucursales y tu operación vive entre Excel, ERPs distintos y WhatsApp manual, no necesitas adaptarte a un SaaS B2B genérico. Necesitas construir el marketplace que tu operación pide.
Catalizadora entrega en 12 semanas, código a tu nombre, sin retainers, con MAGIA Forge desde 20,000 USD. Para empresas medianas con sistemas fragmentados que requieren marketplace, data lake y reportería en el mismo proyecto, MAGIA Core suele ser el camino. Para marketplace con requisitos técnicos profundos y motor de IA con guardrails, MAGIA Forge.
Llamada de 30 minutos, sin pitch deck, conversación real sobre tu operación.