Documento operativo · Hermano de [[workspace—producto—plan-producto-h2-2026]] (el maestro: análisis, mercado y estrategia). Aquel dice qué y por qué; este dice quién, cuándo y cómo lo vamos cerrando. Preparado el 09-06-2026 (s121). Documento vivo: se revisa al cierre de cada mes.
Cómo usar este documento
- Cada mes tiene: objetivo, bloques de trabajo con tareas, y un hito de cierre medible. El hito es la puerta: si no se cumple, el mes siguiente arranca cerrándolo antes de abrir frentes nuevos.
- Reparto orientativo, no rígido: cada bloque tiene un “quien tira” — la persona que lo empuja y responde por él, no la única que lo toca. Se reparte con libertad sobre la marcha.
- Claude acompaña todo: los bloques técnicos se hacen en sesión con Claude (que carga con el grueso del código); los de negocio tienen soporte de research, redacción y análisis. Ningún bloque asume conocimientos que el equipo no tenga.
- Tu copiloto del plan es
/secre: en tu sesión con Claude, escribe/secrey verás tus tareas (propias, compartidas y de Equipo) con su fecha. Desde ahí marcas avances (en curso / hecha), dejas anotaciones, y conversas con Claude en el hilo de comentarios de cada tarea (te responde firmando como «Claude»). El Gestor de Tareas y/secreson dos puertas a la misma base de datos: lo que tocas en uno aparece en el otro. El chat del hilo es asíncrono — Claude lee y responde cuando abres/secreo la tarea, no en el instante; es un buzón por tarea. - Revisión mensual: el último día hábil de cada mes, 30 minutos los tres: ¿hito cumplido? ¿qué se mueve? Se actualiza este documento y punto. Sin ceremonias.
Leyenda de roles:
| Sigla | Quién | Perfil natural |
|---|---|---|
| [E] | Edu | Producto y visión · decisiones · desarrollo con Claude · infra/deploys · demos |
| [D] | Dani | Desarrollo (backend/frontend) · integraciones · Agent · API |
| [T] | Txell | Negocio y operaciones · prospección · contenido/copy · legal · facturación |
Estas tareas están también en el Gestor de Tareas del WS, agrupadas en el proyecto “Plan Producto H2” (s147), y cada miembro las lleva con Claude vía
/secre(ver arriba). Aquí está el marco completo; el Gestor es el seguimiento del día a día.
JULIO — Producto vendible
Objetivo: que el producto aguante el escrutinio de un desconocido con tarjeta de crédito. Nada de lo que enseñamos puede fallar ni mentir.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| J1 | Red de calidad de Auto-Plan (sem. 1-2) | Golden set de 15-20 planos reales anotados · scorer automático 0-100 · umbral con comportamiento honesto (si la confianza es baja, lo dice y ofrece ajuste manual) · job nocturno en CI con telemetría de calidad | [E] |
| J2 | Signage honesto (sem. 2) | Implementar push real en 2-3 marcas más (BrightSign/Samsung/LG ya a medias) o marcar el resto “solo monitorización” en UI y seed · la página de signage dice qué hace cada marca | [D] |
| J3 | Alerting interno de PROD (sem. 3) | Activar vmalert · conectar las reglas ya escritas (latencia, errores 5xx, BD) · avisos por email/canal · simulacro: provocar una degradación en STAGE y comprobar que avisa | [E] |
| J4 | Capacidad por rack (sem. 3-4) | Potencia (W) y peso (kg) por dispositivo · límites por rack (U/kW/kg) · indicador visual de ocupación en el Rack Editor · aviso al superar límites · reporte de capacidad en PDF | [D] |
| J5 | Preparación comercial (todo el mes) | Pricing real de competidores · lista de 30+ MSPs/integradores ES/UE para septiembre · borradores de Términos de Servicio y Política de Privacidad (RGPD) · primeros textos de la landing | [T] |
Hito de cierre de julio — revisado el 29-07-2026 (acta en la task #206 del Gestor):
-
La demo de Auto-Plan pasa el golden set completo sin fallo, y el job nocturno lleva ≥1 semana en verde→ cerrado por decisión (29-07): la calidad quedó validada por otra vía — afinado a ~99-100% desde mayo y examen de 69 etiquetas del 27-07 (el modelo en la nube acertó 69/69). La red formal (golden set dedicado, scorer 0-100, job nocturno) no se construyó; si las demos de septiembre la exigen, se reabre como tarea dimensionada (task #131). - Ninguna pantalla del producto promete algo que no hace — hecho de facto desde el 31-05 (“Hito B · Honestidad Signage”: marcas con envío real vs solo-monitorización marcadas honestamente; el mecanismo fantasma de despliegue server-side se retiró el 02-07). Fleco menor anotado: la etiqueta visible por marca en la página de signage (la API ya sirve el dato; falta pintarlo en UI) (task #132).
- Una degradación provocada en STAGE genera alerta interna en <5 minutos — verificado E2E el 28-07: caída→email en ~2,5-3 min (task #133).
- Un rack enseña su ocupación U/kW/kg y avisa al superarla — en PROD desde el 16-07 (v1.57.0/v1.57.1, task #134).
- Lista de 30+ design partners candidatos + borrador legal listo para revisión — ⏸️ re-fechada al 15-09 con la vuelta de Txell (task #135).
AGOSTO — Abrir la caja
Objetivo: eliminar todo intermediario humano entre “me interesa” y “estoy pagando”. ⚠️ Mes de vacaciones: los bloques están pensados para no solaparse — cada uno puede avanzar aunque los otros dos estén fuera. El hito se mide el 31, no por semanas.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| A1 | Billing con Stripe | Cuenta Stripe (con Stripe Tax para IVA UE) · checkout + trial 14 días + upgrade/downgrade + cancelación self-service · conectar el module gating con el estado de la suscripción · límites por plan aplicados de verdad · Customer Portal · enlace con Holded | [E] técnica · [T] cuenta/fiscal |
| A2 | Registro self-service + onboarding | Signup público · wizard de primera organización · sandbox con datos de ejemplo · camino guiado al “aha” (<10 min) · emails de activación/bienvenida | [D] |
| A3 | Landing pública | Retomar crearack-landing (con el agente de diseño) · pricing público · página de seguridad · vídeo demo de Auto-Plan (guion [T], grabación [E]) · formulario “agenda una demo” | [E] desarrollo · [T] copy y guion |
| A4 | Legal publicado | Términos de Servicio, Política de Privacidad y DPA revisados y enlazados desde la landing y el signup | [T] |
| A5 | Mini-auditoría de las superficies nuevas | Billing + signup son código nuevo expuesto a internet: pasarles el motor de la Auditoría Suprema (versión reducida) ANTES de abrir el registro · 1-2 sesiones | [E] |
Hito de cierre de agosto:
- Una persona ajena al equipo completa sola el ciclo visita → registro → trial → pago (prueba real con alguien de confianza) y nosotros solo lo vemos en el dashboard de Stripe.
- La landing está publicada con pricing, vídeo y página de seguridad.
- ToS + Privacidad + DPA publicados.
- La mini-auditoría de billing/signup está en verde (0 hallazgos ALTA abiertos).
SEPTIEMBRE — Design partners · captación
Objetivo: pasar de “funciona” a “lo usan”. 5-10 clientes reales (MSPs/integradores) con descuento de fundador a cambio de feedback semanal. A partir de aquí, su feedback manda sobre cualquier plan interno — incluido este documento.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| S1 | Campaña de captación | Contactar la lista de julio (30+) · email/LinkedIn personalizado · objetivo: 10-15 conversaciones → 5-10 partners firmados · condiciones founder: descuento fuerte 12 meses a cambio de 30 min de feedback semanal y permiso para caso de éxito | [T] |
| S2 | Demos y onboarding asistido | Demo en vivo a cada candidato (el golden set de julio garantiza que Auto-Plan no falla) · onboarding acompañado de cada partner: su sala real cargada en la primera sesión | [E] |
| S3 | Local Agent para Linux/Docker | Versión del Agent en contenedor/Linux para la sala del cliente · empaquetado + docs de instalación | [D] |
| S4 | API pública + import | Documentación pública de la API (los ~509 endpoints ya generan OpenAPI) · import desde NetBox y Excel/CSV | [D] |
| S5 | Canal de feedback | Canal directo con los partners · triaje semanal: cada petición se clasifica (ahora/backlog/no) y se responde SIEMPRE · registro con contador de cuántos partners piden cada cosa | [T] registro · [E] decisión |
Hito de cierre de septiembre:
- ≥5 organizaciones reales con su infraestructura cargada.
- Agent corriendo en Linux/Docker en al menos 1 partner.
- API pública documentada y accesible.
- Primer ciclo de feedback completado (todas las peticiones triadas y respondidas).
OCTUBRE — Design partners · consolidación
Objetivo: que los partners pasen de “lo probé” a “lo uso cada semana”. Construir lo que pidan, endurecer lo que rompan, y preparar el lanzamiento con datos reales.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| O1 | Construir lo pedido | Lo que pidan ≥3 de 5 partners se construye este mes · se reserva ~50% de la capacidad de desarrollo para esto | [E]+[D] |
| O2 | Hardening de uso real | Lo que el uso real rompa o atasque (rendimiento con salas grandes, UX confusa, bugs) tiene prioridad sobre features nuevas | [D] |
| O3 | Métricas de producto | Instrumentar activación y retención (qué % llega al “aha”, quién vuelve cada semana) con analytics EU (tipo Plausible/Umami) · panel para la revisión mensual | [E] |
| O4 | Casos de éxito | 2 borradores de caso de éxito con datos reales de partners (con permiso): problema → solución → resultado en cifras | [T] |
| O5 | Pricing final | Validar los tramos con los partners (“¿a este precio lo pagarías sin descuento?”) · ajustar y congelar el pricing del lanzamiento | [T] análisis · [E] decisión |
Hito de cierre de octubre:
- ≥5 organizaciones usándolo semanalmente (medido con O3, no por sensación).
- 2 casos de éxito en borrador aprobados por los partners.
- Pricing de lanzamiento congelado.
- 0 peticiones de partners sin responder.
NOVIEMBRE — Lanzamiento
Objetivo: abrir la puerta al público y que empiece a entrar gente que no conocemos.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| N1 | Apertura del registro | Registro público activo con el pricing congelado · los partners founder mantienen sus condiciones · vigilancia reforzada la primera semana | [E] |
| N2 | Casos de éxito publicados | Página “clientes” en la landing con los 2 casos de octubre · citas reales con nombre y logo | [T] |
| N3 | Contenido SEO inicial | 3-5 artículos pilares con Claude y revisados por el equipo (cómo documentar una sala, NetBox vs CreaRack, mejor DCIM para MSPs, qué es DCIM) · en el blog de la landing | [T] redacción · [E] revisión |
| N4 | Presencia en directorios | Fichas en G2, Capterra y AlternativeTo · primeras reseñas de partners · evaluar Product Hunt | [T] |
| N5 | Soporte a clientes | Definir el canal de soporte (email + Help Widget) · tiempo de respuesta comprometido · plantillas de respuestas frecuentes | [T] proceso · [D] mejoras al Help |
Hito de cierre de noviembre:
- Registro abierto al público y estable (sin incidentes ALTA la primera semana).
- Página de clientes + 3 artículos publicados.
- Fichas en ≥2 directorios con ≥3 reseñas de partners.
- Primeros registros orgánicos (gente que no hemos contactado nosotros).
DICIEMBRE — Primeros ingresos y plan 2027
Objetivo: convertir registros en ingresos, aprender del embudo con datos, y decidir la gran apuesta de 2027.
| # | Bloque | Qué incluye | Quien tira |
|---|---|---|---|
| D1 | Optimización del embudo | Con los datos de oct/nov: ¿dónde se cae la gente? (visita→registro, registro→aha, trial→pago) · atacar el punto de mayor fuga, uno cada vez | [E] |
| D2 | Iteración del onboarding | Mejorar el wizard/sandbox según los drop-offs reales · subir el % que llega al “aha” | [D] |
| D3 | Cierre comercial del año | Convertir trials founder y orgánicos en suscripciones · facturación en orden (Stripe↔Holded cuadrados para el cierre fiscal) | [T] |
| D4 | Retrospectiva + Plan 2027 | Revisión del semestre contra este documento · decidir con datos la apuesta de 2027 (¿capacidad avanzada? ¿programa partners MSP? ¿multi-idioma?) · escribir el PLAN_PRODUCTO_2027 | Los tres |
Hito de cierre de diciembre:
- Primeros ingresos recurrentes self-service (clientes que pagan sin que hayamos hablado con ellos).
- Embudo medido de punta a punta con al menos una mejora aplicada y verificada.
- Plan 2027 escrito y consensuado.
Tablero de hitos H2 (vista de pájaro)
| Mes | Hito en una frase |
|---|---|
| Junio | 0 dominios sin auditar + Informe Supremo |
| Julio | La demo de Auto-Plan no puede fallar en público; el producto no promete nada que no haga |
| Agosto | Un desconocido puede probar y pagar sin hablar con nosotros |
| Septiembre | 5+ organizaciones reales con su infraestructura cargada |
| Octubre | Esas organizaciones lo usan cada semana; pricing congelado |
| Noviembre | Registro abierto; primeros registros orgánicos |
| Diciembre | Primeros ingresos recurrentes self-service; plan 2027 decidido |
Carga orientativa por persona
No es un contrato — es para ver de un vistazo que el reparto es razonable y dónde apoyarse:
- Edu [E]: el hilo técnico-producto de principio a fin (Auto-Plan, alerting, Stripe, landing, demos, embudo). Casi todo en sesión con Claude, como hasta ahora.
- Dani [D]: los bloques de desarrollo con entidad propia (signage, capacidad, signup/onboarding, Agent Linux, API/import, hardening). También con Claude en su perfil.
- Txell [T]: toda la cara de negocio (pricing, prospección, legal, copy, casos de éxito, directorios, soporte, cierre fiscal). Claude apoya en research y redacción; nada requiere perfil técnico.
Riesgos y amortiguadores
| Riesgo | Amortiguador |
|---|---|
| Agosto es agosto (vacaciones) | Bloques independientes entre sí; el hito se mide el día 31. Si A1-A3 se cumplen, A4-A5 pueden deslizar 1 semana a septiembre sin romper nada |
| La captación de septiembre rinde poco (<5 partners) | La lista de julio es de 30+; ampliar a segunda tanda + pedir referencias a los firmados. Antes que bajar el listón, alargar 2-3 semanas |
| Los partners piden algo grande no previsto | Para eso está el 50% reservado de octubre. Si excede eso, es candidato a apuesta 2027, no a colarse en noviembre |
| Crédito/capacidad de Claude en meses intensos | Priorizar por hito: lo que no bloquea el hito del mes, espera. La Auditoría ya nos enseñó a trocear y presupuestar sesiones |
| Algo de junio se desliza (terminal es enorme) | Julio admite cerrar colas de auditoría en paralelo a J1-J4 sin mover el hito |
Qué NO está en este plan (a propósito)
- Power-chains, PDUs inteligentes, cooling avanzado — terreno Sunbird/Schneider; candidato a 2027 si los partners lo piden.
- Multi-idioma del producto — la UI va en inglés; mercado España/UE arranca así. Candidato 2027.
- White-label / partner program formal — primero validar que los MSPs pagan el producto tal cual.
- Mobile app — el producto es responsive; nadie lo ha pedido aún.
Documento vivo. Revisión: último día hábil de cada mes, 30 minutos, los tres. Fuente de verdad en esta wiki (el .md del repo CreaRack-Pro se archivó el 2026-06-17, s147). Estrategia y mercado: [[workspace—producto—plan-producto-h2-2026]].
Véase también
- [[workspace—producto—plan-producto-h2-2026]]