ComandeskHelp Inicio

Plan estrategico de producto: Comandesk vendible

Fecha: 2026-05-24

Estado: version operativa tras fases 1-6 de mejora UX/readiness

Tesis

Comandesk no debe venderse como "un agente autonomo que lo hace todo". Esa promesa es demasiado amplia y hoy genera decepcion cuando el usuario espera acceso automatico al disco, ejecucion sin preparacion o contexto perfecto.

La promesa vendible y defendible es:

> Comandesk convierte proyectos en trabajo ejecutable con trazabilidad: scope, plan, tareas, specs, readiness, credenciales, targets, runners y primera ejecucion supervisada.

El valor no es reemplazar al agente local ni al IDE. El valor es coordinar el trabajo antes, durante y despues de la ejecucion, dejando evidencia, tiempos y siguiente paso.

Problemas detectados

  • La experiencia era incomoda para proyectos largos: al refrescar se perdia el cockpit y el usuario volvia al dashboard.
  • El nombre y contexto del proyecto se diluian entre demasiados datos.
  • La ejecucion autonoma parecia mas preparada de lo que realmente estaba.
  • El agente no puede acceder al disco del usuario desde SaaS sin un runner local autorizado.
  • La estrategia solo SaaS limita casos donde el cliente necesita trabajar con modelos locales o repos privados.
  • El flujo de crear proyecto, scope, plan, tareas, specs y ejecucion no estaba lo bastante guiado.
  • Faltaba registrar tiempo incluso en tareas no facturables para entender el coste real del producto.

Promesa comercial recomendada

Lo que si se puede vender ya

  • Cockpit de proyecto persistente.
  • Planificacion guiada: scope -> plan -> tareas -> specs.
  • Readiness de ejecucion por proyecto.
  • Configuracion guiada de credenciales y targets.
  • Modos de ejecucion explicitos: SaaS worker, runner local y repo/remoto.
  • Primera ejecucion segura mediante preflight supervisado.
  • Trazabilidad de tareas, comentarios, evidencias y tiempo.

Lo que no debe prometerse todavia

  • Acceso automatico al disco del usuario desde SaaS.
  • Ejecucion autonoma sin preparar credenciales, target, runner o repo.
  • Publicacion/despliegue sin gates humanos.
  • Soporte universal de cualquier proveedor, modelo o entorno local sin configuracion.
  • Billing autoservicio completo.
  • Marketplace publico de agentes o skills.

Modelo de producto

SaaS

Bueno para:

  • clientes no tecnicos;
  • equipos que quieren cola, usuarios, proyectos, auditoria y credenciales centralizadas;
  • automatismos que no necesitan leer disco local;
  • workers controlados por la plataforma.

Requisito:

  • no vender acceso local directo;
  • explicar que las credenciales viven en boveda;
  • mantener gates humanos en acciones sensibles.

Local

Bueno para:

  • usuarios tecnicos;
  • proyectos con repos o archivos privados en la maquina;
  • modelos locales;
  • tareas que necesitan entorno de desarrollo real.

Requisito:

  • runner local instalado y autorizado;
  • ruta de trabajo definida;
  • permisos claros;
  • logs y evidencia sincronizados con Comandesk.

Guia operativa: Runner local.

Repo/remoto

Bueno para:

  • equipos que aceptan Git como frontera de trabajo;
  • ejecucion reproducible en branch, PR o worktree remoto;
  • clientes que no quieren exponer su disco local.

Requisito:

  • conectar proveedor Git sin circunscribirse solo a GitHub;
  • crear o enlazar repositorio por proyecto;
  • credencial de deploy o token con alcance minimo;
  • estrategia de commit, PR y rollback.

Guia operativa: Repositorios por proyecto.

Flujo principal de producto

  1. Crear proyecto.
  2. Escribir scope minimo.
  3. Generar plan.
  4. Generar tareas y specs desde el plan.
  5. Revisar readiness.
  6. Configurar lo que falte: flujos, subagentes, credenciales o target.
  7. Elegir modo de ejecucion: SaaS worker, runner local o repo/remoto.
  8. Crear preflight de primera ejecucion.
  9. Ejecutar una tarea pequena.
  10. Cerrar con evidencia, tiempo y siguiente paso.

Roadmap honesto

Fase A: Base vendible

Estado: en ejecucion, con fases 1-6 desplegadas.

  • Cockpit persistente.
  • Auto-refresh sin perder proyecto.
  • Barra de contexto del proyecto.
  • Wizard scope -> plan -> tareas.
  • Readiness visual y accionable.
  • Presets de targets y credenciales desde readiness.
  • Preflight por modo con tiempo estimado.

Fase B: Runner local comercializable

Objetivo: que el modo local sea instalable, explicable y soportable.

  • Paquete de runner local.
  • Token de vinculacion por workspace/proyecto.
  • Heartbeat visible en readiness.
  • Prueba de acceso a ruta antes de ejecutar.
  • Guia de instalacion para Mac/Linux/Windows.
  • Soporte de modelos locales cuando el runner los declare.

Fase C: Repositorios por proyecto

Objetivo: que repo/remoto no dependa de una sola plataforma.

  • Abstraccion de proveedores Git.
  • Crear o enlazar repo por proyecto.
  • Soportar GitHub primero, pero modelar GitLab, Forgejo/Gitea y URL Git generica.
  • Branch/worktree por ejecucion.
  • Evidencia de diff/commit/PR.

Fase D: SaaS beta controlada

Objetivo: invitar clientes sin prometer autonomia total.

  • Onboarding por invitacion.
  • Flujos plantilla limitados.
  • Credenciales con recetas.
  • Readiness por cuenta/workspace.
  • Soporte directo y feedback.
  • Automatismos sensibles desactivados por defecto.

Fase E: Monetizacion

Objetivo: cobrar por coordinacion operativa, no por fantasia de autonomia.

  • Plan Personal local-first.
  • Plan Team SaaS con workspaces y auditoria.
  • Add-on runners gestionados.
  • Add-on soporte/setup.
  • Add-on automatismos recurrentes.

Criterios de venta

Un cliente puede entrar si:

  • acepta empezar con primera ejecucion supervisada;
  • tiene 1-3 casos de uso claros;
  • entiende si su caso requiere SaaS, local o repo;
  • no necesita ejecucion sin gates en acciones sensibles;
  • esta dispuesto a revisar evidencia al principio.

Un cliente no debe entrar aun si:

  • exige autonomia total desde el dia uno;
  • necesita acceso local sin instalar runner;
  • no puede usar repositorio ni runner;
  • quiere billing/marketplace/self-service completo;
  • quiere delegar datos sensibles sin revisar permisos.

Metricas de producto

  • Tiempo desde crear proyecto hasta primera tarea con spec.
  • Tiempo desde readiness bloqueado hasta readiness parcial/listo.
  • Numero de preflights creados por proyecto.
  • Porcentaje de preflights que terminan con evidencia.
  • Tiempo humano registrado por fase.
  • Tareas automaticas cerradas sin evidencia: debe tender a cero.
  • Tareas bloqueadas por credencial, target o runner.
  • Retencion de proyectos con segunda ejecucion.

Siguiente decision

La siguiente apuesta de producto deberia ser runner local + repositorios por proyecto, porque resuelve la mayor friccion real: ejecutar trabajo con acceso a archivos sin fingir que el SaaS puede leer el disco del usuario.

La UI ya debe seguir empujando al usuario por el camino honesto: primero scope, luego plan, despues tareas/specs, readiness, configuracion, preflight y solo entonces ejecucion.