Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarydiscipline and process / 2026-05-01

Building Aris Space: 8 Hours, 5 Sessions, One Site

How aris-space.com got built end-to-end with Claude in 8 hours, across 5 sessions, never breaking 50% context.

6 parts / Hover to explore. Click to read.

How aris-space.com got built end-to-end with Claude in 8 hours, across 5 sessions, never breaking 50% context.

Session: one bounded phase
            |
       build + check
            |
       written handoff
            |
      fresh session
            |
   verify state -> continue
Written handoffs carried the build between sessions with room left for verification. The reported context limit belonged to this build, not a universal model threshold.
Five coloured session blocks stacked with handoff arrows and a 50% capacity bar
Five sessions, each capped at 50% context, handed off in writing

What shipped that day

This version of aris-space.com took eight hours across five sessions. None went above 50% context.

At the time, the stack was Next.js 15, Tailwind v4, MDX, Zustand and react-rnd, deployed on Vercel. The build ended with 14 commits in the website repository, four in the orchestration root, and 19 of 19 unit tests passing.

Those are the numbers from that build, rather than a description of every later version of the site. What I want to keep using is the way the work moved between sessions.

Close the session while it still makes sense

My rule for this build was a 50% context cap.

That wasn't a claim that every model fails at the same percentage. It was a working limit based on the behaviour I was seeing: sessions rereading material, reopening settled decisions and becoming less precise as the conversation filled up.

I wanted enough room left to finish the phase, check it, and describe its state properly. If you wait until the session is struggling, you're asking it to write the handoff at exactly the wrong moment.

The handoff cost roughly ten minutes at each boundary. In return, the next session could start with the relevant decisions and files instead of a long conversation to untangle.

How the five sessions divided the work

Session one: the workspace. We made the spec, decisions log, manifest and repository scaffolding. The handoff said the foundation was ready.

Session two: the desktop shell. Window management, draggable panes and the System 7.5.3 treatment. The shell worked; the content was still empty. That distinction belonged in the handoff.

Session three A: the content layer. MDX, topic routing and the registry. This session ended partway through the phase, with an account of what was connected and what remained.

Session three B: finish the content layer. A new session read that account and continued the same phase. A phase boundary is useful, but you shouldn't force the rest of a phase into a session that's running out of room.

Session four: integration and launch. Analytics, MCP wiring, deployment, smoke tests and two live posts.

Each handoff answered the same questions: what's done, what's next, what didn't work, and what is actually saved on disk? Anything important that existed only in the conversation had to be written down.

For non-trivial work, I also started with a short brainstorm about the shape, edge cases and definition of done. Finding the wrong assumption there was much cheaper than finding it after implementation.

Let the agent use the tools

The analytics setup showed why tool access mattered.

Claude used an MCP server to reach the live PostHog project. It read the settings, retrieved the project key, set the website's Vercel environment variables and enabled session recording. I reviewed the changes and confirmed them.

That was a specific action in that build, with those tools and access available. The general idea is simpler: an MCP server can expose operations the agent can carry out from the working session. You don't have to shuttle every detail between a dashboard and the chat yourself.

The agent still needs the right access and a clear boundary for what it may change. Tool access lets it act; the working agreement tells it when it should.

The system around the AI is the intelligence.

Keep the results and the limits together

  • Eight hours across five sessions.
  • 14 commits in the website repository and four in the orchestration root.
  • 19 of 19 unit tests passing at the end of that build.
  • No session above the chosen 50% context limit.

This is one build, not a guarantee that the same process makes every site an eight-hour job. It gave me a way to keep the work understandable as it moved.

I directed the result. Claude carried out the implementation. The spec, handoffs, checks and tool access made that division practical.

Try the handoff first: before your next session ends, write what exists, how you checked it, and what the next session should do. Then open the next one and see whether it can continue without asking you to reconstruct the project.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 8