Método SOCLE
Framework de creación de producto digital en 5 etapas secuenciales. Cada etapa produce entregables concretos que alimentan la siguiente.
Principio
Se prepara el terreno completo antes de construir la primera característica visible. Cada decisión se toma una sola vez, en orden. Las bases técnicas se colocan en una sola pasada, incluyendo lo que se construirá más tarde. El desarrollo avanza por incrementos cortos, cada uno completo y desplegado antes de pasar al siguiente.
Las 5 etapas
S — Estructurar las decisiones
Comenzamos por las decisiones que importan. A quién nos dirigimos, qué problema resolvemos, qué tecnologías, cómo medimos. Una a la vez, en orden, y cada una abre la puerta a la siguiente.
Entregables de esta etapa:
- Visión del producto en una frase
- Usuario objetivo (persona primaria y secundaria)
- Problema resuelto (específico, medible)
- Stack técnico bloqueado
- Dirección visual elegida
- Modelo de monetización identificado (incluso si es freemium, incluso si es más adelante)
- Nombre del producto
Cómo proceder:
- Hacer preguntas de encuadre con opciones cerradas (sin lluvia de ideas abierta)
- Bloquear cada decisión antes de pasar a la siguiente
- Consolidar en una tabla de decisiones bloqueadas
- Identificar competidores y diferenciadores
Leer references/structurer-checklist.md para la lista completa de decisiones a tomar.
O — Herramientas del terreno
Se prepara todo el terreno en una sola pasada. La base de datos, las páginas, la autenticación, el seguimiento, las convenciones. Todo está listo, incluso para lo que se construirá más adelante.
Entregables de esta etapa:
- Estructura de rutas definitiva (las URLs no cambiarán)
- Esquema de base de datos completo (todas las tablas, incluso las no usadas en V0.1)
- Design tokens CSS (variables, tipografía, colores, espaciado)
- Variantes de animación (Framer Motion o equivalente)
- Plan de tags de analytics (eventos, funnel de conversión)
- Pipeline CI/CD (lint, type-check, tests, build automático)
- Archivo CLAUDE.md (instrucciones del proyecto para Claude Code)
- Archivo CURRENT_INCREMENT.md (alcance del primer incremento)
- Configuración de middleware (auth, redirecciones, cabeceras de seguridad)
- Variables de entorno documentadas
Cómo proceder:
- Generar la estructura de rutas completa (marketing, auth, app, admin, API)
- Escribir el esquema SQL completo con enums, índices, RLS, triggers
- Configurar el sistema de diseño (globals.css + tailwind.config.ts)
- Crear los archivos de contexto del proyecto (CLAUDE.md, ARCHITECTURE.md, etc.)
- Scaffold el proyecto, instalar todas las dependencias, primer commit, desplegar
Leer references/outiller-templates.md para las plantillas de cada archivo.
C — Construir por piezas
Avanzamos por incrementos cortos. Cada incremento entrega algo completo, que se puede mostrar, probar, usar. Una pieza real de producto, que funciona de principio a fin.
Principios:
- Cada incremento tiene un alcance cerrado escrito en CURRENT_INCREMENT.md
- Cada incremento tiene criterios de finalización comprobables
- Cada incremento tiene una lista explícita de lo que está fuera del alcance
- Las tareas están ordenadas: cada tarea depende únicamente de las anteriores
- Cada tarea sigue el ciclo: codificar, probar, verificar, commitear
Estructura de un incremento:
# V0.X — [Nombre del incremento]
## Objetivo
[Lo que el usuario puede hacer al final de este incremento]
## Tareas (en orden)
[Lista numerada de tareas con detalle]
## Criterios de finalización
[Lista de verificaciones concretas]
## Fuera del alcance
[Lista explícita de todo lo que NO está en este incremento]
Verificaciones sistemáticas después de cada tarea:
- El type-check pasa
- Los tests pasan
- No hay tipos
any - Las props están tipadas
- Los inputs de API están validados
- El commit sigue conventional commits
L — Entregar en cada etapa
Cada pieza está en línea y en manos de usuarios reales antes de pasar a la siguiente. Los comentarios llegan temprano, los ajustes también.
Principios:
- Cada incremento se despliega a producción (o previsualización) tan pronto como termina
- El deploy es automático (push en main = deploy en Vercel)
- Los errores de producción se detectan de inmediato (monitoreo, error boundaries)
- Los eventos de analytics están activos desde el primer incremento
- No se comienza el siguiente incremento hasta que el anterior sea estable
Checklist de entrega:
- Build pasa en CI
- Cero errores en consola en producción
- Las páginas tienen metadatos (title, description)
- El responsive funciona (verificar en móvil)
- Los eventos de analytics están trackeados
- La URL es accesible y funcional
E — Expandir sin reconstruir
El producto crece naturalmente. Las nuevas funcionalidades se apoyan en lo que existe, el diseño evoluciona, las integraciones se conectan. La estructura se mantiene estable porque el terreno estaba listo desde el principio.
Principios:
- Los nuevos incrementos nunca invalidan los anteriores
- Las tablas de la base de datos ya están listas (añadidas en la etapa O)
- Las variables CSS permiten cambiar el estilo sin tocar los componentes
- Las rutas son estables (las URLs no cambian)
- Las convenciones de código son las mismas desde el primer hasta el último incremento
Cuando se añade un incremento:
- Actualizar CURRENT_INCREMENT.md con el nuevo alcance
- Verificar que las bases (etapa O) cubren las necesidades
- Si falta una tabla o ruta: añadirla mediante migración, no mediante reconstrucción
- Codificar, probar, desplegar siguiendo las mismas convenciones que V0.1
Cómo aplicar SOCLE a un nuevo proyecto
Secuencia completa
1. ESTRUCTURAR
│ Conversación de encuadre (preguntas cerradas)
│ Tabla de decisiones bloqueadas
│ Visión, objetivo, stack, monetización
↓
2. HERRAMIENTAS
│ Generar todos los archivos de base
│ Rutas, DB, tokens, analytics, CI/CD
│ Scaffold, deploy, primer commit vacío
↓
3. CONSTRUIR (V0.1)
│ Primer incremento: el núcleo mínimo
│ Auth + una característica core + un export
│ Tests, commit, deploy
↓
4. ENTREGAR (V0.1)
│ En producción, probado por usuarios reales
│ Analytics activos, errores monitorizados
│ Estable antes de pasar a V0.2
↓
5. EXPANDIR (V0.2, V0.3, ...)
│ Cada incremento sigue C → L
│ Las bases absorben el crecimiento
│ Sin reconstrucción
Archivos de proyecto a generar (etapa O)
| Archivo | Rol |
|---|---|
CLAUDE.md | Instrucciones para Claude Code: convenciones, flujo de trabajo, verificaciones |
CURRENT_INCREMENT.md | Alcance del incremento en curso, tareas ordenadas, criterios de finalización |
ARCHITECTURE.md | Rutas definitivas, estructura de archivos, flujo de datos |
DB_SCHEMA.sql | Esquema completo de la base de datos |
DESIGN_TOKENS.md | Variables CSS, configuración de Tailwind, variantes de animación |
AGENT_PROMPTS.md | Prompts del sistema si el proyecto utiliza agentes de IA |
ROADMAP.md | Vista general de todos los incrementos previstos |
Auditoría de complejidad (entre S y O)
Antes de pasar a la etapa O, hacer un inventario de todos los componentes del proyecto y evaluar su complejidad. Si el número de componentes de alta complejidad supera los 5, dividir en más incrementos. La regla: cada incremento contiene como máximo de 3 a 5 componentes nuevos.
| Componente | Complejidad | Incremento previsto |
|---|---|---|
| [nombre] | Baja / Media / Alta | V0.X |
Si el proyecto se asemeja a una catedral (más de 20 componentes, más de 6 de alta complejidad), revisar el alcance. Simplificar el V0.1 hasta que sea realizable en una o dos semanas por una persona.
Stack técnico recomendado
El método SOCLE funciona con cualquier stack. Aquí está el stack por defecto si el usuario no tiene preferencia:
| Capa | Tecnología |
|---|---|
| Framework | Next.js 14+ (App Router) |
| Lenguaje | TypeScript estricto |
| Estilos | Tailwind CSS + shadcn/ui |
| Animaciones | Framer Motion |
| Estado | Zustand |
| Auth | Supabase Auth |
| Base de datos | Supabase (PostgreSQL) |
| Validación | Zod |
| Tests | Vitest + Testing Library |
| CI/CD | GitHub Actions |
| Deploy | Vercel |
Si el usuario tiene un stack diferente, adaptar las plantillas de la etapa O en consecuencia. Los principios SOCLE siguen siendo los mismos independientemente del stack.
Tono y postura
Cuando se aplica SOCLE con un usuario:
- Tono profesional, maduro, conversacional
- Frases claras y directamente útiles
- Sin jerga técnica no explicada cuando se habla con un no desarrollador
- Sin postura de superioridad
- Sin construcciones retóricas ("no es X, es Y")
- Se guía, se transmite, se avanza juntos