01
Discovery
~1 semanaEntendemos antes de construir.
Mapeamos procesos, fricciones y dónde está la palanca real. Entrevistamos a tu equipo, revisamos sistemas existentes y validamos hipótesis con datos.
Entregable: PRD con OKRs medibles
Cómo trabajamos
Spec-Driven Development.
Un proceso de 5 fases con roadmap en tiempo real, evidencia objetiva por feature y hand-off documentado. Sin caja negra.
El proceso
Las 5 fases, paso por paso.
Cada fase tiene su entregable y su criterio de aceptación. No avanzamos a la siguiente sin cerrar la anterior.
02
Spec
~3-5 días por specCada feature parte de una página de texto.
Redactamos specs funcionales y técnicas que tú apruebas explícitamente. Cero scope creep silencioso, cero malentendidos. Si no se puede escribir, no se construye.
Entregable: Spec aprobada + plan técnico
03
Build
según specImplementación con commits atómicos.
Cada commit responde a una tarea concreta del plan. PRs pequeños, revisables. Roadmap en vivo: tickets, PRs, deploys y métricas en un panel compartido contigo.
Entregable: Código en repo + roadmap visible
04
Verify
~1 día por featureEvidencia objetiva, no promesas.
Cada feature se prueba contra su spec antes del PR: raw outputs de tests, screenshots, métricas de bundle, smoke en todas las rutas. Si algo falla, lo verás ahí.
Entregable: verify.md con evidencia raw
05
Deploy & Hand-off
continuoCI/CD con rollback en un click.
Release a producción con preview environments por PR. Tu equipo recibe documentación viva (ADRs, READMEs, tests) y puede operar el código desde el día uno.
Entregable: Release + docs + hand-off session
Principios
Lo que sostiene el proceso.
Tres reglas que aplicamos siempre, independiente del proyecto o el cliente.
Commits atómicos.
Cada commit es una unidad lógica que se puede revertir aisladamente. Sin "wip", sin lotes gigantes.
Evidencia, no opinión.
Todo cambio lleva verify.md con outputs raw. Cuando decimos "funciona", hay tests, screenshots y métricas que lo prueban.
Hand-off documentado.
ADRs, READMEs y diagramas vivos. Tu equipo puede leer el código en seis meses sin pedirnos ayuda.
Preguntas frecuentes
Lo que más nos preguntan.
¿Por qué empezar con una spec antes de codificar?
Una spec obliga a tres cosas: definir qué resuelve, por qué, y cuál es la métrica que mueve. Si no se puede escribir en una página, probablemente no está claro qué se está construyendo — y eso siempre cuesta más caro corregirlo en código.
¿Y si cambian los requisitos a mitad del proyecto?
Es lo esperable. Cuando un requisito cambia, actualizamos la spec primero (en §0bis del plan), validamos contigo, y solo después tocamos código. Eso evita que el equipo construya algo basado en supuestos viejos.
¿Cómo veo el progreso en tiempo real?
Cada proyecto entrega un panel compartido con tickets, PRs, deploys y métricas. Tú decides la frecuencia de stand-ups, pero el estado siempre está disponible 24/7 — no esperas al reporte semanal.
¿Qué pasa con el código si decidimos no continuar el contrato?
El código vive bajo tu organización desde el día uno. Si decides parar, te quedas con todo: repositorio, infraestructura, docs y tests. Sin licencias propietarias ni dependencias ocultas.
¿Cuánto tarda este proceso vs un sprint tradicional?
En la primera feature suele tardar un 10–20% más por las specs y la documentación. A partir de la 3ra feature el proceso es más rápido que el tradicional porque tu equipo ya entiende el código, los tests cubren regresiones y los rollback son inmediatos.
Disponibles para Q3 2026
¿Aplicamos este proceso a tu próximo proyecto?
Conversa con nuestro copiloto. Alcance, timeline y rango de inversión en minutos.