Crafter Pass · Crafter’s Lab Membership
Build your apps. Grow your studio.
This is a workshop for serious builders who care about the craft. We learn through real product work, question how it gets done and develop better ways to build our own apps and studios.
Build the system that builds your apps.
Using an agent to write code is only the beginning. The bigger shift is building the system that can carry an app from intent to checked work, without asking you to reconstruct the method for every change. You are developing the product and the capability to build the next one.
Turn good practice into repeatable work.
The context you gather, the decisions you record and the checks you trust should not disappear when a task ends. Give them a place in your agents and workflows. Connect those workflows into a software factory, so the way you research, build and review becomes something your studio can use again.
Improve the system, not just the result.
When something goes wrong, get close enough to understand it. Fix the code when the code needs fixing. Improve the agent’s context, tools or workflow when the method is the problem. The aim is not to stay above the details. It is to turn what you learn there into a better way of working.
Let each app strengthen your studio.
That is the direction I’m pursuing through native Apple apps: useful products, and a stronger system behind each one. A dependable workflow can serve another app. A lesson from one project can improve the next. You keep the product judgment and the craft, while more of the repeated work becomes capability your studio can carry.
Build the agents that build your apps.
Context, model, prompt and tools. Those are the four foundations I keep coming back to. The opportunity is not just to get a better answer from them, but to build agents that can carry more of the work.
Tools have been around for years. With agentic coding tools like Claude Code, we can connect them into workflows that keep going beyond a single exchange: making changes, running checks, working through failures and documenting the result. A run might take minutes or hours. What matters is whether the work holds up, not how long the agent stays busy.
That changes where I put my attention. Instead of steering an agent through every change, I can work on the agent itself: the context it receives, the model I choose, the instructions that guide it and the tools it can use. Every improvement can help the next run, not just the task in front of me.
That is what I’m building toward in my studio. Agents that can do more of the work, with workflows I can inspect and improve. I still decide what deserves to be built, what needs a closer look and whether the result is good enough to ship. The leverage is not giving up the craft. It is building the capability that gives me more room for it.
Four overlapping circles: context and tools above, model and prompt below, each overlapping its neighbours.
Why Notion?
I didn’t choose Notion because I knew it would become my command center. When I started freelancing, I was already using it to document my work and track my coding sprints.
Then it became a place to work with clients. We could keep the context together, follow the work and collaborate in the same space. Eventually, I was setting up Notion for their businesses too. It was already part of how I worked long before agents joined the picture.
When I started working with AI agents, coordinating with them there made more and more sense. The place I used to organize my own work gradually became the place where I could direct the work of a studio.
I can work from my MacBook or another device while the agents on the Mac mini reach that same context through MCP, browser use or connectors. We don’t have to use the same interface to work in the same place. That is how Notion became my command center, not because it is the only way to build one, but because it grew with the way I work.
Where I’m taking the Lab.
I know the direction: I’m building my AI-native studio, and the Lab is where I share what I’m learning so you can develop your own. What I don’t know is exactly what this work will look like three years from now.
The tools are moving quickly. The way we build, and even the devices we use to do it, could look very different by then. I’m not going to pretend I can predict all of that. I can tell you what I’m working toward and why I believe it deserves the next three years.
That is why I’ve put a timeline on this chapter, from January 2027 through December 2029. It gives the work a clear horizon and a point to question what the Lab should become next. The direction is deliberate. The next chapter should reflect what we’ve learned, not a promise made today about a future none of us has seen.
- January 2027The chapter begins
- 2027–2029Build, share, improve
- December 2029Review the chapter and decide what comes next
Before you join.
One more think, this is for serious builders who care about the craft. It isn’t a beginner’s introduction or a promise that one prompt will build your app. You need to be willing to do the work, question the results and improve the way you build.
The Teamspaces share parts of my working studio, not a template pack. You’ll find work in progress, decisions that changed and systems I’m still improving. Copying them won’t give you a studio. Understanding why they’re shaped this way helps you develop your own, and yours will look different. It should.
I keep Crafter small on purpose, so the rooms stay a place where people talk about real work. If that’s what you’re looking for, I’d love to have you here.