01
Socrático
Cuestionar la idea antes de construirla.
- Documento de objeciones propias
- 3 escenarios de fracaso
- Decisión go / no-go registrada
Metodología propiaEn uso diarioDesde 2025
APEX.
Cómo trabajo, no qué vendo.
APEX es el sistema de 14 fases que me permite entregar en 4 semanas lo que a otros les lleva 8. No es un producto que puedas comprar — es la metodología con la que construyo cada proyecto desde el primer día.
Por qué existe
Después de construir varios proyectos (DNI Chatbot, FeedbackIA, Osyris-Web, Zyndra), identifiqué un patrón: los proyectos no fallaban por falta de habilidad técnica, sino por falta de estructura. Se empezaba a programar sin analizar el problema, se saltaba el testing, y se entregaba tarde o con deuda técnica insostenible.
El desarrollo asistido por IA amplifica el problema: el agente no tiene memoria entre sesiones, no sabe en qué fase del proyecto está, y tiende a saltar directamente al código. El resultado es código que funciona en demo pero no en producción.
APEX es mi respuesta a ese problema. Un sistema MCP con SQLite como cerebro persistente del proyecto, búsqueda full-text FTS5 sobre decisiones, y fases obligatorias con criterios de verificación.
Principios
Pensar antes de teclear.
La fase socrática es obligatoria. Antes de una sola línea de código, cuestionamos si la idea vale la pena y qué haría que fracasara.
Memoria persistente por proyecto.
Cada decisión, error y componente queda registrado en una base SQLite con búsqueda full-text. El agente que me ayuda mañana sabe lo que decidí hoy.
Fases secuenciales, criterios explícitos.
No se avanza a la siguiente fase hasta que la anterior tenga un criterio de hecho verificable. Se acabaron los proyectos al 80% eternamente.
Temporal facts, no dogmas.
Las decisiones se pueden invalidar cuando cambia el contexto. El sistema recuerda qué se pensó y por qué, pero no lo convierte en ley.
Las 14 fases.
Secuenciales, obligatorias, con criterio de hecho explícito. Ninguna se puede saltar; todas se pueden revisitar.
Descubrimiento
02
Investigación de mercado
¿Existe el problema fuera de tu cabeza?
- Competidores identificados
- Rangos de precio validados
- Entrevistas o evidencia pública
03
Análisis del problema
Aislar el dolor concreto, no la solución soñada.
- Usuarios y personas
- Jobs to be done
- Dolores medibles
04
Propuesta de valor
Qué ganamos nosotros y qué gana el cliente.
- Promesa central en una frase
- Prueba tangible disponible
- Diferenciador defendible
Diseño
05
SPEC + checkpoints
Saber qué hay que entregar y cuándo se sabe que está hecho.
- Funcionalidad core vs extendida
- Checkpoints con criterio de hecho
- Restricciones no negociables
06
Arquitectura (C4 + Design System)
Decidir la forma antes de tallar el material.
- Diagrama C4 contexto + contenedores
- Design system con tokens
- ADR de decisiones estructurales
07
Modelo de datos
Entidades, relaciones y flujos de información.
- Diagrama ER o esquema de datos
- Contratos entre capas
- Política de persistencia
08
User flows
Cada pantalla tiene un objetivo medible.
- Flujos principales ilustrados
- Edge cases declarados
- Criterios de éxito por flujo
Construcción
09
Scaffold
Montar el esqueleto del proyecto en horas, no en días.
- Repo con estructura y tooling
- CI verde desde el primer commit
- Conventional commits activos
10
Implementación
Ejecución iterativa con check-ins semanales.
- Features completas por checkpoint
- Testing continuo
- Decisiones registradas en contexto
11
Testing
El código que importa no se entrega sin red de seguridad.
- Tests unitarios en lo crítico
- Prueba end-to-end del flujo estrella
- Checklist de QA antes de deploy
Operación
12
Deploy
Estar online no es el final; es el comienzo.
- Infraestructura reproducible
- Variables de entorno documentadas
- Observabilidad mínima (logs + analytics)
13
Documentación
Que otra persona pueda tomar el relevo.
- README operativo
- CLAUDE.md con reglas del proyecto
- Handover con onboarding en <1 día
14
Mantenimiento
Pensar la v2 antes de que se rompa la v1.
- Plan de backups y recuperación
- Política de actualización
- Plan de deprecación si aplica
Resultado en proyectos reales
14
Fases guiadas
6+
Proyectos construidos
100+
Decisiones trackeadas
~50%
Reducción de tiempo
Por qué te importa
Cuando contratas un pack Forge o Citadel, no contratas a alguien que improvisa. Contratas este sistema.
Cada decisión queda registrada. Cada fase tiene un entregable verificable. Cada proyecto se documenta en vivo en un wiki interno que se entrega con el código. Si mañana te contrata otro desarrollador para mantener lo que hicimos, abrirá el proyecto y entenderá por qué se tomó cada decisión en 10 minutos.
¿Quieres ver APEX aplicado a tu proyecto?
30 minutos de diagnóstico. Salimos con un primer análisis socrático de tu idea y una estimación honesta de si vale la pena construirla.