How to start your first cycle
A concrete, sequential walkthrough. Follow this page and complete a real cycle.
Before you start
You need a real problem worth solving — not a practice exercise. The framework produces better results when the stakes are real, even if they're small.
If you haven't already, read the Introduction to understand the core loop, and the Why solveOS guide to understand the principles.
Research (optional, recommended for your first cycle)
Use Research when you don't yet understand the problem space well enough to write a reliable Plan Brief.
If you already know the problem well, skip to Step 2.
When to use it: You're working in a domain you haven't worked in before. Your problem statement is based on assumptions you haven't validated. The constraints are unknown.
How to run it: Define one specific research question — not "learn more about X" but "what are the existing solutions to this problem and their limitations?" Set a time limit (30–60 minutes for small decisions). Document what you find and write conclusions.
Plan: write your Plan Brief
The Plan Brief is the single most important artifact in the framework. Write it. Don't keep it in your head.
The Plan Brief is not a starting artifact — it is a compass. You will refer back to it throughout Build. Every ambiguity in it becomes a guess in the output.
Answer these eight questions:
- What is the problem? What is actually broken, missing, or needed? State the problem, not the solution.
- Who is this for? Who experiences this problem? Who will use or read what you build?
- What is the goal? What does a successful outcome look like, specifically? Start with a verb.
- What is the appetite? How much are you willing to invest? This is a conscious bet, not an estimate. Scope is variable within it.
- What are the constraints? Skills, dependencies, non-negotiables beyond the appetite.
- What is the success criteria? How will you know, objectively, that this is done?
- What is the core assumption? What must be true for this plan to work?
- What are the rabbit holes? What unknowns could drag the build into territory you don't want to explore in this cycle?
Use this template:
## Plan Brief
**Problem**
[One or two sentences. What is broken, missing, or needed? Be specific.]
**Audience**
[Who experiences this problem? Who will use, read, or interact with what you build?]
**Goal**
[One sentence. What does success look like? Start with a verb: "Build", "Write", "Fix", "Define".]
**Appetite**
[How much are you willing to invest in this cycle? This is a bet, not an estimate. Scope should fit inside it.]
**Constraints**
- [Constraint 1]
- [Constraint 2]
**Success Criteria**
- [ ] [Measurable criterion 1]
- [ ] [Measurable criterion 2]
- [ ] [Measurable criterion 3]
**Core assumption**
[What must be true for this plan to work?]
**Rabbit holes**
[What unknowns are you explicitly setting aside for this cycle?]
**Out of scope**
[Explicitly list what you are NOT solving.]Validate the plan
Run this on your first cycle. Run it on any cycle where the stakes are high or the plan feels vague.
Hand the Plan Brief to someone else (or an AI) and ask:
- Is the problem correctly stated?
- Is the plan feasible?
- Is it specific enough to build from without asking clarifying questions?
If gaps are found — go back to Plan and sharpen the brief. If all three are a clean yes — proceed to Build.
Build
Start from the success criteria, not from the full brief. The success criteria are your anchors.
After each unit of work, ask: does this still connect to the goal? If yes, continue. If no, stop and decide — either the goal evolved (update the Plan Brief) or you drifted (course correct).
If the plan needs updating during Build: Update it in writing before continuing. Never let the plan become a fiction you are quietly ignoring.
Validate the build (optional)
Run this before any public-facing release, or when the output is complex.
Test each success criterion as pass or fail. A fail means fix before shipping, or explicitly descope it. Document any accepted limitations.
Ship
Do the actual shipping action. Deploy, publish, send, release, present, hand off.
Do not stop at "ready to ship." Ship. Then confirm it is live — check it from the perspective of your intended audience.
Review
Run a post-ship review after real-world signal is available — not immediately after shipping.
For each success criterion: was it met, and how do you know? Evidence must come from outside yourself. Then write feed-forward inputs for the next Plan.
Start the next cycle
The output of the Review is the starting point for the next Plan. Every cycle starts smarter than the last.
Cómo iniciar tu primer ciclo
Un recorrido concreto y secuencial. Sigue esta página y completa un ciclo real.
Antes de empezar
Necesitas un problema real que valga la pena resolver — no un ejercicio de práctica. El framework produce mejores resultados cuando las apuestas son reales, aunque sean pequeñas.
Si aún no lo has hecho, lee la Introducción para entender el ciclo central, y la guía Por qué solveOS para entender los principios.
Research (opcional, recomendado para tu primer ciclo)
Usa Research cuando aún no comprendes el espacio del problema lo suficiente como para escribir un Plan Brief confiable.
Si ya conoces bien el problema, ve directamente al Paso 2.
Cuándo usarlo: Estás trabajando en un dominio en el que no has trabajado antes. Tu enunciado del problema se basa en supuestos que no has validado. Las restricciones son desconocidas.
Cómo ejecutarlo: Define una pregunta de investigación específica — no "aprender más sobre X" sino "¿cuáles son las soluciones existentes a este problema y sus limitaciones?" Establece un límite de tiempo (30–60 minutos para decisiones pequeñas). Documenta lo que encuentres y escribe conclusiones.
Plan: escribe tu Plan Brief
El Plan Brief es el artefacto más importante del framework. Escríbelo. No lo guardes solo en tu cabeza.
El Plan Brief no es un artefacto de inicio — es una brújula. Lo consultarás durante todo el Build. Cada ambigüedad en él se convierte en una suposición en el resultado.
Responde estas ocho preguntas:
- ¿Cuál es el problema? ¿Qué está roto, qué falta o qué se necesita? Enuncia el problema, no la solución.
- ¿Para quién es? ¿Quién experimenta este problema? ¿Quién usará o leerá lo que construyas?
- ¿Cuál es el objetivo? ¿Cómo se ve un resultado exitoso, específicamente? Comienza con un verbo.
- ¿Cuál es el apetito? ¿Cuánto estás dispuesto a invertir? Es una apuesta consciente, no una estimación. El alcance es variable dentro de ella.
- ¿Cuáles son las restricciones? Habilidades, dependencias, elementos no negociables más allá del apetito.
- ¿Cuáles son los criterios de éxito? ¿Cómo sabrás, objetivamente, que esto está terminado?
- ¿Cuál es el supuesto central? ¿Qué debe ser verdad para que este plan funcione?
- ¿Cuáles son los pozos sin fondo? ¿Qué incógnitas podrían arrastrar el build hacia territorio que no quieres explorar en este ciclo?
Usa esta plantilla:
## Plan Brief
**Problema**
[Una o dos oraciones. ¿Qué está roto, qué falta o qué se necesita? Sé específico.]
**Audiencia**
[¿Quién experimenta este problema? ¿Quién usará, leerá o interactuará con lo que construyas?]
**Objetivo**
[Una oración. ¿Cómo se ve el éxito? Comienza con un verbo: "Construir", "Escribir", "Corregir", "Definir".]
**Apetito**
[¿Cuánto estás dispuesto a invertir en este ciclo? Es una apuesta, no una estimación. El alcance debe caber dentro.]
**Restricciones**
- [Restricción 1]
- [Restricción 2]
**Criterios de éxito**
- [ ] [Criterio medible 1]
- [ ] [Criterio medible 2]
- [ ] [Criterio medible 3]
**Supuesto central**
[¿Qué debe ser verdad para que este plan funcione?]
**Pozos sin fondo**
[¿Qué incógnitas estás dejando explícitamente de lado en este ciclo?]
**Fuera de alcance**
[Lista explícitamente lo que NO estás resolviendo.]Valida el plan
Ejecuta esto en tu primer ciclo. Ejecútalo en cualquier ciclo donde las apuestas sean altas o el plan parezca vago.
Entrega el Plan Brief a alguien más (o a una IA) y pregunta:
- ¿El problema está correctamente enunciado?
- ¿El plan es factible?
- ¿Es lo suficientemente específico para construir sin hacer preguntas aclaratorias?
Si se encuentran vacíos — vuelve al Plan y afina el brief. Si los tres son un sí claro — procede al Build.
Build
Comienza desde los criterios de éxito, no desde el brief completo. Los criterios de éxito son tus anclas.
Después de cada unidad de trabajo, pregunta: ¿esto todavía conecta con el objetivo? Si sí, continúa. Si no, detente y decide — o el objetivo evolucionó (actualiza el Plan Brief) o te desviaste (corrige el rumbo).
Si el plan necesita actualización durante el Build: Actualízalo por escrito antes de continuar. Nunca dejes que el plan se convierta en una ficción que estás ignorando en silencio.
Valida el build (opcional)
Ejecuta esto antes de cualquier lanzamiento público, o cuando el resultado sea complejo.
Evalúa cada criterio de éxito como aprobado o reprobado. Un reprobado significa corregir antes de entregar, o descartarlo explícitamente. Documenta cualquier limitación aceptada.
Ship
Realiza la acción real de entrega. Despliega, publica, envía, lanza, presenta, entrega.
No te detengas en "listo para entregar". Entrega. Luego confirma que está en vivo — verifícalo desde la perspectiva de tu audiencia objetivo.
Review
Ejecuta una revisión post-entrega cuando haya señal del mundo real — no inmediatamente después de entregar.
Para cada criterio de éxito: ¿se cumplió y cómo lo sabes? La evidencia debe provenir de fuera de ti mismo. Luego escribe los aportes futuros para el siguiente Plan.
Inicia el siguiente ciclo
El resultado del Review es el punto de partida del siguiente Plan. Cada ciclo comienza con más inteligencia que el anterior.