Plan de Producto H2-2026: de producto excelente a producto que se vende

Documento para la reunión de equipo · Preparado el 09-06-2026 (s121). Base: análisis del producto (Máster + GAPS + Auditoría Suprema) contrastado con el mercado DCIM 2026. Audiencia: Edu, Dani, Txell. Escrito en llano; los términos técnicos van explicados la primera vez.

El “quién, cuándo y cómo” (desglose mes a mes con tareas, hitos y reparto) vive en el documento hermano: [[workspace—producto—plan-ejecucion-h2-2026]].

1. Resumen ejecutivo

CreaRack Pro es un producto técnicamente por delante de su negocio. En un solo SaaS tenemos lo que el mercado vende como 4-5 productos separados (editor visual de racks, monitorización de red, digitalización de planos con IA, terminal SSH, signage), sobre una base de seguridad multi-tenant que estamos sellando dominio a dominio con la Auditoría Suprema.

El hueco de mercado existe: el mercado DCIM (software de gestión de infraestructura de datacenter) vale ~4.300 M$ en 2026 y crece al ~18% anual, pero los líderes (Sunbird, Device42, Schneider) son caros y enterprise, y la alternativa gratis (NetBox) es árida y sin visual. El 99% de las salas de servidores del mundo —PYMEs, MSPs, integradores— no tiene una herramienta a su medida. Ahí encajamos.

Lo que falta no es ingeniería, es la capa comercial: hoy no hay forma de descubrir CreaRack (sin landing), probarlo (sin registro self-service) ni pagarlo (sin billing automatizado). El plan de los próximos 6 meses invierte ese orden: junio sella la seguridad, julio hace el producto vendible (calidad Auto-Plan, promesas honestas, capacidad), agosto abre la caja (Stripe + signup + landing), sept-oct valida con 5-10 clientes reales, nov-dic lanzamiento abierto.

En una frase: tenemos un Ferrari en el garaje con la puerta cerrada. Toca abrir la puerta.

2. Qué tenemos hoy (la foto honesta)

2.1 El producto

8 módulos sobre una base multi-tenant común (multi-tenant = cada organización cliente ve solo sus datos):

2.2 La base invisible (pero vendible)

La Auditoría Suprema (en marcha desde el 02-06) lleva ~350 hallazgos confirmados y corregidos en 5 dominios (core, racks, blueprints, monitoring, network): aislamiento entre clientes a nivel de base de datos (RLS), credenciales cifradas con clave dedicada, permisos revisados endpoint a endpoint. Además: datos alojados en la UE (Hetzner), IA europea-friendly (Gemma vía Google AI Studio, sin enviar datos a terceros opacos).

Esto hoy no se ve desde fuera. Convertirlo en una página pública de seguridad es marketing casi gratis.

3. El mercado y el hueco

• Mercado DCIM 2026: ~4.280 M$, creciendo al ~18% anual hasta ~9.900 M$ en 2031 (Mordor Intelligence).
• Motores del crecimiento: IA, edge computing (salas pequeñas distribuidas, justo nuestro cliente) y la presión por monitorizar consumo energético.
• El gasto en datacenter de las PYMEs crece al ~7% anual (~57.000 M$ en 2025).

Competidores y por qué no nos pisan

Conclusión: entre “Excel + Visio” (donde vive hoy la mayoría) y “Sunbird a precio enterprise” hay un desierto. CreaRack es el único con editor visual + monitorización + IA + puente a red privada en el mismo producto y a precio comprensible.

4. Diagnóstico comercial

Fortalezas (lo que ya nos diferencia)

1. Auto-Plan AI — “sube la foto de tu plano, mira tu sala digitalizada en minutos”. Es el mejor gancho de captación posible y nadie más lo tiene.
2. Local Agent — el SaaS llega a la red privada del cliente sin abrir puertos. Barrera de entrada técnica real para competidores.
3. Bundle completo — diseño + monitorización + terminal en uno; el cliente pequeño no quiere 4 herramientas.
4. Datos en la UE — argumento GDPR limpio que Device42/Freshworks no puede igualar.
5. Seguridad auditada — material de confianza que la mayoría de startups no puede enseñar.

Carencias (lo que nos frena para vender)

1. No hay forma de comprarlo: sin landing pública (el repo crearack-landing está parado desde mayo), sin pricing visible, sin registro self-service, sin billing automatizado (Holded es facturación manual). Los planes Starter/Pro/Custom existen en código pero los asigna un admin a mano.
2. El gancho no tiene red: la calidad “100%” de Auto-Plan la sostiene solo el prompt, sin validación automática del resultado. Una demo fallida ante un prospecto cuesta la venta.
3. Promesas que no se cumplen (contra nuestra Regla 13): Signage lista 12 marcas de pantallas pero solo SpinetiX (+3 parciales) tiene integración real; las otras 7 caen a un modo genérico en silencio.
4. Falta el corazón clásico del DCIM: gestión de capacidad (¿cuántas U libres tengo? ¿cuánta potencia/peso soporta este rack?). Hoy solo hay un campo de consumo por dispositivo.
5. El Agent solo es Windows — los MSPs (nuestro mejor canal) viven en Linux/contenedores.
6. Alerting interno de PROD endeble — si vamos a tener clientes de pago, no podemos enterarnos de las degradaciones solo por UptimeRobot.

5. Posicionamiento propuesto

“El DCIM para el 99%: salas de servidores, edge y MSPs. Visual, con IA, datos en la UE, y a un precio que entiendes en 10 segundos.”

• Cliente primario: MSPs e integradores IT (una venta = N salas de sus clientes) y PYME/mid-market con 2-50 racks. Hospitales, universidades, fábricas, ayuntamientos.
• Pricing simple por rack, no por dispositivo (el dolor de Device42). Propuesta inicial a debatir:
  • Starter — gratis o muy barato, 1-2 racks, Rack Editor + Terminal. El anzuelo.
  • Pro — tramos por nº de racks (p. ej. hasta 10 / hasta 25), todos los módulos.
  • Custom/Partner — MSPs multi-cliente, volumen, white-label futuro.
• Auto-Plan como onboarding: el primer contacto con el producto es subir su plano y ver magia. De ahí al inventario vivo.
• Signage: se reposiciona como add-on para integradores AV, con la promesa acotada a las marcas que funcionan de verdad. No es pilar del pitch.

6. Roadmap junio → diciembre 2026

Las fases 1-3 van detalladas a continuación. El desglose operativo completo de julio a diciembre (tareas por mes, hitos de cierre y reparto orientativo de roles) está en [[workspace—producto—plan-ejecucion-h2-2026]].

7. FASE 1 · Junio (en curso) — Sellar la casa

Es la continuación directa de la Auditoría Suprema (Etapa 1, en marcha desde s103). Quedan 4 dominios. Método ya calibrado: trocear por sub-áreas (~2-3k LOC), motor reducido 3 finders, verificación adversarial escalonada, fixes “todo de una vez” por sesión.

Semana 9-15 junio · dominio signage (~8,3k LOC → 3 sub-áreas)

• sa1 — CMS core: contenido, playlists, schedules, players (modelos + API signage/).
• sa2 — Deploy/publish: monitoring/api/signage/deploy.py (vive fuera de signage/, footgun conocido), WebDAV vía Agent, SpinetiX.
• sa3 — Adapters de vendors + display control (Samsung MDC, LG, PJLink) + SVG composer.
• Foco esperado: Broken Access Control (el patrón sistémico de los 5 dominios anteriores), credenciales de players, SSRF en URLs de deploy, y documentar de paso qué vendors tienen push real (alimenta la decisión de julio §8.2).

Semana 16-22 junio · dominio terminal/agent (~17,7k LOC → 5-6 sub-áreas, el más grande)

• Priorizar las superficies expuestas: sa1 API sentinel + JWT del Agent (incluye el colateral conocido: receive_agent_alert roto, siempre 500) · sa2 SSH bridge/scrapli + sesiones · sa3 fleet primary/secondary + token recovery · sa4 routes del Agent (signage, traps, cluster) · sa5-6 resto del Agent.
• De paso: CVE asyncssh del Agent (task #81, vencida el 08-06): bump lockfile → smoke SSH/SFTP → rebuild .exe → release. Encaja naturalmente al auditar este dominio.
• ⚠️ Es realista que terminal se coma parte de la semana siguiente — es casi tan grande como monitoring entero.

Semana 23-30 junio · cierre

• Dominios config/IA (pequeño) y frontend (transversal, motor adaptado a JS).
• Etapa 2: consolidación → Informe Supremo (cruce de todos los hallazgos + los 30 GAPS del Máster → backlog priorizado único).
• Backlog Etapa 3 que sigue vivo (decidir en sesión cuáles entran): racks ALTA (restore no atómico, decompression bomb, u_position sin validar) · handler global que filtra str(exc) a los ~509 endpoints (decisión de Edu, es transversal) · Auto-Plan a asíncrono (PR propio, toca frontend) · modularización sentinel.py/library.py.
• Entregable comercial: borrador de la página de seguridad pública (“aislamiento por organización a nivel de BD, credenciales cifradas, auditoría continua, datos en la UE”) — se redacta sola con el Informe Supremo.
• Hito menor: checkpoint D14 del piloto BONSAI (18-06) — veredicto adoptar/descartar.

Criterio de cierre de fase: 0 dominios sin auditar + Informe Supremo publicado en el supercontexto + borrador de página de seguridad.

8. FASE 2 · Julio — Producto vendible

Objetivo: que el producto aguante el escrutinio de un desconocido con tarjeta de crédito. 4 bloques, por orden de prioridad.

8.1 Auto-Plan con red de calidad (inversión nº1 del mes)

El GAPS lo marca como ALTA·comercial: la calidad “100%” no tiene validación automática.

• Golden set: 15-20 planos reales variados (CAD limpio, foto de papel, escaneo torcido, plano denso) con su resultado esperado anotado (nº racks, paredes, conexiones, posiciones aproximadas).
• Scorer automático: compara el resultado generado contra el esperado (estructural, no pixel-perfect) → score 0-100 por run.
• Umbral + comportamiento honesto: si un análisis real sale con confianza baja, el producto lo dice y ofrece reintento/ajuste manual — nunca entrega basura en silencio (Regla 13).
• Job nightly en CI con el golden set (no por PR — coste IA) + telemetría de calidad por run en PROD.
• Bonus desbloqueado: con la red puesta, se puede iterar el prompt sin miedo a regresiones invisibles.

8.2 Signage honesto

• Decisión de equipo (con los datos de la auditoría de junio): implementar push real en 2-3 vendors más (BrightSign/Samsung/LG ya están parciales) o marcar el resto como “solo monitorización” en UI y seed.
• Lo que no se haga, se comunica: la página de signage dice exactamente qué hace cada marca.

8.3 Alerting interno de PROD

• Activar vmalert (hoy comentado en compose.observability.yml) + conectar las reglas ya escritas (alerts.yml: latencia p95, 5xx, errores de BD).
• Canal de aviso: email (Resend) y/o el canal del equipo. Cierra el GAP ALTA “punto ciego de PROD”.

8.4 Capacidad básica por rack (el “DCIM de verdad”)

• Por dispositivo: potencia (W) y peso (kg) — el campo de consumo ya existe, se completa.
• Por rack: límites (U, kW, kg) + indicador visual de ocupación en el Rack Editor + aviso al superar.
• Reporte de capacidad por sala/organización (PDF, como los exports existentes).
• Sin power-chains ni PDU inteligentes (eso es Sunbird) — lo que pregunta un cliente de 10 racks.

Criterio de cierre de fase: demo de Auto-Plan reproducible sin fallo sobre el golden set · ninguna pantalla del producto promete algo que no hace · una degradación de PROD genera alerta interna en <5 min · un rack enseña su ocupación U/kW/kg.

9. FASE 3 · Agosto — Abrir la caja

Objetivo: eliminar todo intermediario humano entre “me interesa” y “estoy pagando”.

9.1 Billing con Stripe

• Checkout + trial 14 días + upgrade/downgrade + cancelación self-service.
• Conectar el module gating existente (los planes ya gatean módulos en código) con el estado de la suscripción + límites por plan (nº racks, dispositivos, usuarios) aplicados de verdad.
• Stripe Customer Portal para facturas/método de pago; Stripe Tax para IVA UE; enlace con Holded para contabilidad (vía la integración existente del workspace).

9.2 Registro self-service + onboarding

• Signup público → wizard de primera organización → sandbox con datos de ejemplo (un datacenter demo precargado para tocar sin instalar nada).
• Camino guiado al “aha”: subir un plano a Auto-Plan o crear el primer rack en <10 min.
• Email transaccional de activación/bienvenida (django-anymail + Resend ya están).

9.3 Landing pública (retomar crearack-landing)

• Pricing público con los tramos de §5 · vídeo demo de Auto-Plan (el gancho) · página de seguridad (de junio) · formulario “agenda una demo” para los que no quieran self-service.
• Diseño “impactante con grandes animaciones” como se planteó en el kickoff de mayo (s51).

Criterio de cierre de fase: una persona ajena al equipo completa sola el ciclo visita → registro → trial → pago, y nosotros solo lo vemos en el dashboard de Stripe.

10. Decisiones a tomar en la reunión

1. Pricing: ¿validamos tramos por rack y los números concretos de cada plan? (propuesta en §5)
2. Signage: ¿implementar 2-3 vendors más o acotar la promesa a SpinetiX+parciales? (§8.2)
3. Design partners: ¿a quién conocemos? Lista objetivo de 10-15 MSPs/integradores (España/UE) para contactar en septiembre — Txell puede liderar la prospección desde ya.
4. Marca/dominio para la apertura: ¿lanzamos como CreaRack en crearack.com tal cual? (Esferic Labs queda como razón social, sin cambios internos)
5. Presupuesto: Stripe (% por transacción), posible coste de vídeo/diseño de landing, crédito IA del golden set nightly.

Fuentes del análisis de mercado

• Mordor Intelligence — DCIM Market Size & Forecast
• Gartner Peer Insights — DCIM Tools
• PeerSpot — Device42 vs Sunbird DCIM
• IoT Analytics — 7 data center trends 2026
• JLL — 2026 Global Data Center Outlook
• Domotz — Best network diagram software for IT teams 2026
• Reanin — SMB spending on data centers

Documento vivo: se revisa al cierre de cada fase. Fuente de verdad en esta wiki (el .md del repo CreaRack-Pro se archivó el 2026-06-17, s147). Desglose operativo mes a mes: [[workspace—producto—plan-ejecucion-h2-2026]].

Véase también

• [[workspace—producto—que-es-crearack-pro]]