How capability develops through the process
The framework is built on cognitive apprenticeship, a model from learning science in which novices develop expert capability by working through real problems alongside structured guidance that makes expert thinking visible.
The structure of the stages, the way each stage surfaces questions before providing answers, the requirement to articulate reasoning at every gate, the session pattern that begins with a pre-session check: these are all part of a situated learning environment in which the project is the curriculum.
Each stage surfaces the questions an experienced builder would ask before proceeding. Expert thinking is made visible for users to internalize and adopt.
The AI responds to the specifics of your project, your constraints, and your decisions. Rather than delivering a course, it is coaching a particular person through a particular problem.
The five-stage structure distributes cognitive load across the project arc. Each stage reduces the problem to one layer. You are never solving everything at once.
The stage gates require you to express your reasoning explicitly: your constraints, your priorities, your architectural decisions. Articulation is the mechanism by which thinking becomes precise.
The Decision Journal, session logs, and stage completion gates require you to account for your choices. Reflection is built into the cadence, creating opportunities for iterative improvement.
The framework provides structure, not scripts. Within each stage, you direct the conversation with your AI tool. The questions are yours. The decisions are yours.
The capability that develops through this process is a better way of working with AI. The user develops a practiced set of instincts for knowing what question to ask next, how to evaluate the answer, and when to push back. That transfers to every future project, in any domain.
Why the app is named Hora
The name comes from Donella Meadows' "Thinking in Systems," a book that shaped much of the thinking behind this framework. In Chapter 3, Meadows retells a fable about two watchmakers.
Hora's watches were no less complex than those of Tempus, but he put together stable subassemblies of about ten elements each. Whenever Hora had to put down a partly completed watch to answer the phone, he lost only a small part of his work. So he made his watches much faster and more efficiently than did Tempus. Donella Meadows, "Thinking in Systems" (2008)
Tempus builds in sequence from a thousand parts. Every interruption costs him everything. Hora builds in stable subassemblies. Interruptions cost him almost nothing. The same principle applies to any complex project worked on across many sessions, often interrupted, always evolving.
The entire framework -- but especially Stage 5 -- is built around this idea. Each session closes with a decision log, an accomplishment note, and a plan update. The project context document captures the full state of the work. When you return after a week, or a month, or six months, Hora can reconstruct exactly where you were.
Two levels of practice, one continuous process.
The framework operates at two levels. Stages 1 through 4 run once per project and establish its foundation. Stage 5 runs continuously for as long as the project is active.
Project Arc
Completed once per project. Defines the problem, scopes the work, designs the architecture, and produces a phased build plan. It's the foundation everything else builds on.
Session Loop
The recurring execution environment. Each session starts with a briefing, runs a focused build effort, and closes with a decision log and plan review. Repeated across weeks and months.
What each stage is for.
Problem Definition
Most projects start with a solution already in mind. "I want to build a dashboard." "I want to automate this process." This stage starts one step earlier: with the frustrations that make a solution necessary.
The work here is tracing symptoms back to causes and distilling what you find into a precise problem statement. That statement is not a deliverable to be filed away. It is the reference point for every decision in every stage that follows. A vague problem statement produces a solution that solves the wrong thing. A precise one focuses the entire project.
The AI's role in this stage is interrogation, not generation. It asks questions you haven't considered, surfaces assumptions you haven't examined, and reflects your reasoning back to you in ways that expose where it is thin. The output is yours.
A Problem Definition Document: a structured account of the problem's domain, root causes, constraints, prior attempts, and the goal a solution must achieve. This document becomes context for every subsequent stage.
Constraint and Scope
Before thinking about features, the framework requires defining what the solution cannot be. Constraints are not limitations on ambition. They are design decisions that shape the solution space before any feature discussions begin. Privacy requirements, hosting preferences, maintenance tolerance, time available: each one rules out categories of solutions and focuses creative energy on what remains.
Feature prioritization follows from constraints. The framework uses a three-tier approach: the minimum viable product (the smallest version that genuinely solves the core problem), the complete product (the full intended scope), and best-in-class (what would make it exceptional). Building out from minimum viable rather than trimming down from best-in-class produces cleaner scope decisions and a clearer first target.
A Constraint and Scope Document: hard limits that any solution must respect, a tiered feature list, and a clear definition of what the MVP must do. This document is carried into Stage 3 as the governing filter for architecture decisions.
Architecture Design
This is the stage where the relationship between the human and the AI is most explicitly a working partnership. The AI brings deep technical knowledge. You bring the problem context, the constraints, and the judgment. Neither substitutes for the other.
The framework insists on understanding the reasoning behind every recommendation before committing to it. The goal is something you can describe to someone else, modify in the future, and debug when something breaks, even if you have never built anything like it before.
Architecture conversations in this framework are tailored to how you plan to build. Someone using a coding agent, a vibe-coding platform, and a chat tool are having fundamentally different architecture conversations. Stage 3 adapts accordingly.
An Architecture Design Document: the technical approach, the tools and stack, the key decisions made and the reasoning behind them. Carried into Stage 4 as the basis for build planning.
Build Planning
Before building anything, the framework requires reviewing what you've decided and building a plan that reflects it. Stage 4 starts with a structured review of the outputs from Stages 1 through 3. This serves as a check against the drift that tends to accumulate between stages.
The build plan that emerges from this stage is phased, specific to your build tool, and grounded in the constraints established in Stage 2. It names what gets built in what order, why that order, and what the completion criteria for each phase are. This document is what Stage 5 works from, and it is designed to be revised rather than abandoned when the plan meets reality.
A Build Plan: phased, sequenced, and scoped to the MVP first. Carried into Stage 5 as the working checklist for the entire build.
Build Execution
Stage 5 is different from the others. It does not run once. It runs every time you sit down to work on the project, for as long as the project is active. Days. Weeks. Months. As many sessions as the build requires.
Each session follows a deliberate pattern. Before building, you generate a session briefing: a structured prompt that gives your AI tool full project context, identifies the current phase and goal, and ends with a question about what the AI sees that you might have missed. You read the response before you build anything. Sessions that start with that exchange consistently surface risks and gaps that would otherwise be discovered much later, at higher cost.
After building, you log what was accomplished, record any decisions made during the session, and note anything that changed in the plan. These records accumulate into a project history that makes every subsequent session faster and more coherent. They also make it possible to return to a project after a break without reconstructing context from memory.
The plan itself is a living document. Features are marked complete, changed, or removed as the build progresses. When something in the plan changes, a note explains why. The plan is a working record of the project's current state and direction.
Start with a briefing, ask what you haven't considered, build, log what happened, record decisions, update the plan. Repeated across every session for the life of the project.
Two tools that run the length of the project.
The five stages produce documents. These two tools are not stage outputs. They are the project's memory.
Decision Journal
Every significant decision made during the project is logged here, including what was decided, why, and what alternatives were considered. Decisions are captured in three ways: via a persistent log-decision button available at any stage, through a structured prompt at the close of any AI session, and by recording the choices made during Stage 3 and 4 conversations.
The journal has two functions. First, logged decisions are context for future sessions, and a record of what was considered prevents relitigating settled questions. Second, articulating a decision clearly enough to write it down is a form of reflection that strengthens the reasoning process itself. Over the course of a project, the journal becomes a record of how you think.
Notes
A freeform space for observations, ideas, and questions that do not fit anywhere else. Notes are not tied to a stage or a session. They exist for the things you want to capture in the moment and return to later: a design question that surfaced during a build session, a scope idea you want to revisit after the MVP, an observation about what is and isn't working.
Notes keep the project journal from becoming a graveyard of unsorted thoughts. They give you a place to think without committing to a decision or interrupting the build.
Four projects. Each one built with this framework.
The projects page documents what was built using this framework, how each project was scoped, and what each one is meant to do. The framework's claims are grounded in these applications, not in the framework itself.
See the projects