Studio Projects
Not every builder is on a client engagement at any given moment. The cohort has more builders than there are seats on client engagements, so some builders are always unstaffed. Being unstaffed says nothing about merit.
If you are not staffed, you are on a studio project. It is the same work held to the same standard, without a client paying for it.
A studio project is real work
A studio project is a real product with real users, built to the Build Standards that govern client work. It ships. On the sprint menu it is a Build for your own product, planned, reviewed, demoed, and graded exactly like client work. The only difference is that no client pays for it.
It matters for three reasons.
It is how you get staffed. Engagements are staffed by reputation, and reputation comes from work people have seen. A shipped studio project, with sprint reviews and demos behind it, is the strongest evidence you can offer that you can do a kind of work you have not done for a client yet.
It is how the Foundry can take on engagements. The Foundry can only take an engagement when it has more than one builder who can do that kind of work. Studio projects are where builders get that experience.
It is where you can practice what a Claude course teaches. Client work is unpredictable and will not use every skill on a schedule. A studio project is yours to shape, so you can deliberately build the thing a Claude course teaches, an evaluation harness, an MCP server, a Skill, and count it as a Learn item in the same sprint. See The Certification Track.
Shape
| Team | Solo or a pair. No larger |
| Hours | The same 10 per week that a client engagement would take |
| Duration | One semester, extendable to two if it still has active users |
| Surface | One product surface. The same rule that governs client engagements |
| Users | Aim for at least three people outside the Foundry using it for their own reasons by the end of the project. Each sprint plan names at least one |
Users are how you find out whether the product works. Find your first one before you start building. The three-user aim is a standard to work toward; it is not graded.
What qualifies
A studio project has to be something a client could plausibly have paid for. In practice that means it meets three requirements:
- It solves someone’s actual problem. A demo, a reimplemented tutorial, or a model wrapper with no user in mind does not qualify.
- Claude does real work in it, through the API, an agentic loop, an MCP integration, or all three. If removing the AI leaves the product intact, pick something else.
- It runs somewhere other than your laptop. Deployed, reachable, and running when you are asleep.
Your first sprint plan on a studio project says what the problem is, who its users are or will be, and what shipping looks like.
How it is graded
A studio project is graded the way every sprint is graded: Plan, Output, Review, and Demo, on the same rubric as client work. See Sprints. Your users take the place of the client: they are the people your plan names under Who will see it, and what they said or did is your answer to the second retro question. Colleague and client feedback works the same way; see The Developmentship Model.
A studio project earns the same points as client work. Being unstaffed does not cost you points.
When you finish, decide what happens to it next: hand it to another builder, open it up, fold it into a Foundry engagement, or shut it down. Shutting something down and saying why is a sound answer, and it belongs in that sprint’s review.
Getting staffed from here
If a new engagement needs the kind of work you just shipped, say so to Professor Murff, and point to the sprint where it shows. When you are staffed partway through a sprint, run /sprint-plan again and note the change. It costs nothing.