← Back to Portfolio
H
Case Study8 min read

The studio runs
on agents.

Skills, subagents, memory, headless execution. The Claude Code harness that lets one person operate a multi-app studio. Built and run solo over a year, under real release pressure.

10+
Products run
1
Operators
1y
Year of evolution
24/7
Headless execution
Scroll to explore
00The Problem

Ten products. One operator.

Sapplify runs six mobile apps across three stores, a production SaaS in seven EU countries, a marketing pipeline, an analytics dashboard, and a lead-generation system. Six brands, three platforms, dozens of internal tools. None of that is a story about working harder. Working harder runs out at one person.

What actually scales a solo studio is making the agent a colleague. Not a code-completion tool, not a chat sidebar. A worker with delegated responsibilities, persistent context, and the autonomy to act between sessions. This case study is the operating layer I built around Claude Code over the last year to make that real.

01Architecture · Four Primitives

Skills, subagents, memory, CLI.

The harness is composed from four building blocks. Skills package domain expertise that the agent loads on demand: how to ship an Android build to internal track, how to draft a marketing post in the studio voice, how to migrate a Supabase schema safely. Subagents are workers the controller dispatches in parallel for independent tasks — each gets its own context window and reports back when done. Memory holds typed entries (who I am, what I prefer, what is in flight, where things live) that persist across sessions. A studio CLI ties it together with one-line commands that wrap multi-step operations.

None of these are exotic. The interesting part is what falls out when they compose. A new session reads the memory index, loads the right skills for the work at hand, dispatches subagents for parallelizable steps, and produces results that look like they came from a small team. On top of the four primitives, three operational patterns: verification (controllers audit subagent claims), focus discipline (the agent enforces sanctioned work against the operator), and headless execution (agents that run without an operator present).

Tech Stack
Claude CodeCustom skillsSubagentsTyped memorystudio CLI
Blocks
Skills, subagents, memory, CLI
Patterns
Verification, focus discipline, headless execution
Result
Sessions operate at small-team productivity, single-operator overhead
02Delegation · Verification Gate

Workers report intent. Controllers verify reality.

The most useful pattern in the harness is also the most dangerous. Dispatching a subagent to do work in parallel and trusting its DONE report is useful because subagents can churn through independent tasks while the controller orchestrates. It is dangerous because the report is what the subagent meant to do, not what actually landed on disk. Subagents know what they meant to change. They do not inspect the diff they committed and compare it against the task scope. If the working tree had pre-existing staged files, or if the subagent touched files as side effects, those ride along in the commit silently.

The countermeasure is structural. Every DONE report is treated as a claim that must be verified before the next step proceeds. After a subagent commits, the controller inspects the diff. If files outside the scope appear, the commit is split: cherry-pick the intended changes, reset the rest. The subagent is never trusted with the final word on what it changed. This single guardrail eliminated a whole class of silent regressions that used to surface days later in unrelated products.

Tech Stack
Controller / subagent splitgit show --statCherry-pick split
Pattern
Controllers dispatch, subagents work, controllers audit
Mechanism
Diff inspection after every claimed commit
Lesson
Trust intent. Audit reality.
03Persistence · Typed Memory

What persists between sessions.

Without memory, every session starts cold. With ad-hoc memory, the agent accumulates contradictions. The harness uses a typed memory system: every entry is one of four kinds. User entries describe who I am and how I work. Feedback entries are rules the agent should apply (including why, so it can judge edge cases). Project entries track ongoing work and decisions. Reference entries point to where information lives in external systems. One index file lists them; entries link to each other by name when they relate.

The constraint that makes this work is what does not get saved. Code patterns, file paths, git history, project structure — anything derivable from reading the current state — are out. The memory is for what the codebase cannot tell you: preferences, scars, in-flight decisions, where the bodies are buried. Everything else is recomputed from the project at session start. That discipline keeps the memory small, current, and worth the read.

Tech Stack
Typed entriesIndex fileNamed linksMarkdown
Types
User · Feedback · Project · Reference
Discipline
Do not save what is derivable from the code
Shape
One index, one file per entry, linked by name
04Discipline · Focus Lock

The agent enforces against the operator.

Solo operators drift. The agent is tuned to be helpful, which means saying yes to scope expansion. Operators are opportunistic — if the agent is already loaded with context, why not drain the adjacent backlog? Together they wander. A session that started on Task A ships changes to D, E, and a half-finished F. Task A is still open the next morning.

Focus lock moves scope discipline into the system prompt where the agent can enforce it. The current sanctioned work is named explicitly. The agent is instructed to push back when I drift — not as a one-time nudge, but on every drift attempt. There is a tangent-capture file so good ideas do not vanish, and an explicit override phrase for legitimate re-prioritization. The key move is that the agent is asked to be the disciplinarian, not me. The agent has the consistency to push back ten times in a row where I would cave after two.

Tech Stack
System prompt guardrailsTangent captureOverride phrase
Mechanism
Sanctioned work named in system prompt, agent enforces
Release valve
Tangent capture file, explicit override phrase
Insight
Agents should enforce constraints, not just follow them
05Autonomy · Headless Execution

Work that happens while I sleep.

The harness has agents that run without a human at the keyboard. A scheduled job kicks off overnight, surveys a domain (lead pipeline, content backlog, social calendar), and either drafts work for review or — for narrow, well-scoped tasks — completes it end to end. The output lands in a queue I review when I wake up.

Headless execution is where the harness pays back the most and breaks the worst. It pays back because the agent operates outside my working hours, multiplying available time. It breaks worst because there is no operator in the loop to notice when something goes sideways. The discipline that compensates is narrow scope, observable artifacts (every run leaves logs), and human gates before anything that affects the outside world (publishing, payments, communications). The agent works. The operator approves. The studio runs through the night.

Tech Stack
Scheduled triggersLog artifactsHuman approval gates
Scheduler
Cron-style triggers running scoped tasks
Boundary
Agents draft, humans gate external effects
Effect
Available operator time multiplies past 24 hours per day
What I’m Learning

The interesting work
is in the in-between.

Agents are most useful when trusted with autonomy, and least reliable precisely because of that autonomy. The version of Claude Code I would want to build is the one where verification is structural, not voluntary. I wrote about three specific failure modes in detail.