Our app store is live. Agents wrote almost all of it.

Our app store went live this month. Software we build for the water: from a boat show that never closes to a health coach designed for life at sea. Everything runs in the browser; most of it installs like a native app.

3D Boat Show (beta): the boat show that never closes. Photograph a boat, get a 3D version of it, and put it in a virtual marina that is open at three in the morning in another time zone. Boat shows are a handful of weekends a year in a handful of harbours; the buyers are everywhere, all year.

Yacht Empire (beta): build a charter empire from your father's boat, in the Balearics. A tycoon simulation with a written story across twenty chapters, and the economy underneath it tuned by a simulation that plays the whole game start to finish on every meaningful change.

Healthy Crew (in development): the coach who shows you how, and explains why, adapted for life on board. Training, nutrition and recovery that assume a galley and a moving deck rather than a gym and a supermarket.

More are in the pipeline. What they have in common is not the subject matter; it is how they were made. Between them they carry well over 1,300 commits, and a human wrote almost none of them.

That is not a claim about speed. It is the setup for the rest of this piece, because making it work took a system.

The system: Founder OS

Every startup runs the same handful of processes: work out whether the idea holds, find out who the customer is, build the thing, sell it, raise money for it, and keep the books straight. Most founders run them out of their head, badly, in whatever order the day imposes. We wrote them down instead, as agents.

Founder OS is the result: agents grouped into seven modules, covering pre-seed through Series A.

Each column is a discipline; each cell is an agent with its own instructions, tools and outputs.

The columns are the disciplines. Strategy decides whether there is a business at all: feasibility, business model, competitors, vision and OKRs. Market works out who actually buys: customer intelligence, research, journey mapping, nurturing. Sales & Distribution turns that into a go-to-market motion and the two engines behind it, B2B and B2C. Product & Tech Delivery designs it, builds it, measures whether it holds, and re-architects it when it stops scaling. Capital runs the fundraising machinery, from investor matching through term sheets to grants and eventual M&A. Finance & Legal keeps unit economics, the model, legal guardrails and monitoring honest. Team & AI Agents covers the people and the internal agent infrastructure itself.

They interlock rather than sit side by side. Vision and OKRs feed the roadmap that Agentic Dev builds against. Design Mockup produces what Agentic Dev implements. The PMF Tracker measures whether what shipped actually held, and its findings return as work. Unit Economics constrains what is worth building at all. The rule of thumb we use: anything that lands in git and a user touches belongs to Module 16; anything that keeps the company running internally belongs to Modules 28 and 30.

Module 16 is the one that built everything in the store, so it is the one we are opening up.

How agentic development actually works

Start with what an agent is, in practice, because the popular picture (a chatbot that returns a code snippet) is not it.

An agent is a model running in a loop with three things attached. First, a harness: the standing instructions that tell it what this project is, which rules bind it, and what it may decide on its own. Second, tools: it reads and writes files, runs the test suite, queries the deployment pipeline, and, through MCP connectors, reaches everything else the work needs. In our case that includes generating images and video for the products themselves; Yacht Empire's art and its animated sequences were produced through the same loop that writes its Dart code. Third, a memory of what happened: the specs, the decisions, and the hard-won lessons written down in the repository, so the next agent starts where the last one finished rather than from zero.

What makes it useful is not that it writes code. It is that the same loop closes all the way around the product.

That right-hand box is the part most setups leave out, and it is the one that matters most. A user reports something inside the app; it lands in a live backlog with its source attached; the loop picks it up on priority, builds the fix, verifies it, ships it through the gate, confirms in production that it actually landed, and the user is told. No human sat in the middle transcribing.

The same is true in the other direction. A deploy that silently failed used to be something we discovered days later by accident, scrolling through a CI list. Now the loop checks the pipeline run, compares the version marker actually being served against the commit it shipped, and calls the health endpoint. A deploy is not done when the command exits. It is done when the thing you deployed answers.

Why a rulebook, when the model already knows how to code

The obvious objection: modern models are good. Why not point one at the repository and let it work?

Because knowing is not complying. A capable model knows perfectly well that you do not delete a failing test to make the pipeline green, and under pressure, in a long session, it sometimes does it anyway. It knows what a good commit looks like and still drifts off the format. The gap between competence and consistency is where a rulebook earns its keep, and the asymmetry underneath is brutal:

An agent produces more code in ten minutes than a person can review in ten minutes. And wrong code looks exactly as convincing as right code.

So we wrote down what the model cannot know: our decisions. Not a prompt library but an operating manual. Here is what is in the package.

The blueprint

The binding rulebook, deliberately short. Where every kind of information lives. The hierarchy from product definition to roadmap to spec to commit, and the rule that nothing may contradict the level above it. Roadmap limits: at most three things in progress, because more parallel work produces context loss, not speed. The one rule everything else derives from: never hand off work you have not verified yourself. "Looks done" is not a signal; an executed check is.

The harness

How to decide when the rules run out, which is most of the interesting moments. A priority ladder for when two things conflict: correctness, then security and data integrity, then reversibility, then the stated requirement, then consistency, then simplicity, then shipping something small. And decision confidence: every open decision gets scored by where its answer came from. From the spec or a recorded decision, it scores high and the agent proceeds and logs why. From nothing at all, it is queued for us: bundled once, never as five interruptions. We set the threshold. The clever part is what happens after: when a decision gets queued, the agent records which missing document would have raised its score. Write that document and autonomy grows: by adding information, not by growing bolder.

The contracts

Six roles, each with a mandate and a hard boundary: product proposes priority but never sets it; the builder writes code but never approves or merges it; QA verifies but never fixes what it finds; security reports but never holds deploy credentials; release ships, and only a human can invoke it. The sixth is an orchestrator that stands in for the product owner between their decisions: it owns what gets built next and why, and nothing about how the code is written. Without that role the actor running the loop is the only one with no mandate, so it drifts into the code, into the detail, and into asking the founder what it should decide itself.

An agent that writes code and approves its own code has no verification loop; it has a rubber stamp. And the boundaries are structural, not aspirational: QA and security can only read, so they are technically incapable of changing what they judge.

The workflows

Nine named sequences, because a hotfix is not a refactor. Each is a table of steps with a gate between them: who acts, what they do, what must hold before the next step starts. A bug fix begins with a failing test, always. A refactor must leave the test suite untouched, because that is the only proof behaviour did not change. A hotfix compresses everything except the reproducing test, the verification chain, and the postmortem. And one standing meta-workflow, the autonomous loop, that runs the others around the clock.

The guardrails

Four levels, because a rule that is only written down gets followed most of the time, and at a hundred changes a week, "most" is not enough. Prose covers everything and enforces nothing. Contracts bind roles. Hooks block locally and immediately: force-pushing to main, bypassing pre-commit checks, deploying from a laptop, printing secrets; those exit with an error, not a warning. CI gates are the last line, and they apply to humans too. The rule of thumb for adding one: if a violation is merely annoying it stays prose; if it destroys work or endangers security it gets a hook and a gate.

The orchestrator loop

This is the part that changes what one person can ship. An orchestrator agent stands in for the product owner between your decisions, and runs the workflows continuously. The trick is that it does none of the work itself: it grooms the backlog against the roadmap, groups related items into a bundle, then delegates every piece, the build to a builder, the checks to a verifier, the review to a reviewer. Because it never sits blocked inside a task, it stays responsive, and the queue keeps moving. A recurring trigger keeps it turning, so the product develops overnight and at weekends rather than only when somebody opens a laptop. Work waiting on your approval is finished, opened for review and set aside, and the loop carries on without it. The decisions only you can take arrive bundled, once.

The learning loop

Rules are written after incidents, never before. Preventive rules inflate a rulebook without preventing anything, and an inflated rulebook stops being read, at which point the rules that do matter stop working too. When something breaks in one product, the lesson is written down; if it would happen in any project, it travels upstream to the shared module and reaches every other product on the next update.

Upstreaming is publishing, though, and the module repository is public. So a learning is scrubbed before it leaves the project: anything project-specific is stripped, or the learning is held back rather than guessed at, and whatever was removed is reported. A learning sent upstream with internals still in it is not a contribution, it is a disclosure.

This is not theory. On the day we adopted the module in our health app, its first pipeline run exposed two defects in our own security template: a secret scanner that crashed before scanning, which from a distance looks exactly like a scanner that passed, and a vulnerability check that can never succeed on a private repository.

The project filed the incident upstream, the fix went into the shared module, and the release was tagged and distributed the same afternoon. Incident in one product, rule change in the module, update in every product. That path is the entire reason to build it this way.

How to use it

Open the project you want to convert in Claude Code, and paste this:

Set this project up for Founder OS: write .claude/settings.json declaring the
marketplace github: steffenmaas/founder-os under extraKnownMarketplaces and
enabling agentic-dev@founder-os under enabledPlugins, commit and push it.
Then clone steffenmaas/founder-os and follow
plugins/agentic-dev/docs/adopt-existing-project.md from step 1.

That is the whole installation. Claude writes the settings file, commits it, fetches the module and walks the adoption guide with you: it surveys what you already have, keeps what works, writes down your existing decisions so no agent re-litigates them, wires the backlog, and sets the thresholds. From the next session on, every session in that repository loads the rules, the roles and the guardrails automatically.

Then hand it the loop:

Work autonomously per .founder-os/workflows/autonomous-loop.md: pull from the
backlog, bundle, ship through the deploy gate, refresh the dashboard, re-arm
every ~15 minutes. Contact me only for deploy-gate approvals, queued decisions,
or finished milestones.

From there you watch a dashboard rather than a terminal: what is in flight, what shipped, what is waiting on a decision from you and, importantly, what could not be verified. That last line is the most valuable thing an agent can tell you.

One caveat, plainly: this is calibrated for a small team shipping a product, where the founder is both product owner and bottleneck. It assumes small batches, continuous deployment, and someone who wants to be involved in fewer decisions over time rather than more. If your compliance regime requires a named human approval on every change, the gate is configurable, but you will be working against the grain.

---

Founder OS · Module 16: Agentic Dev is at github.com/steffenmaas/founder-os, under the PolyForm Noncommercial licence: free for founders, teams, non-profits and education. The three apps it built: 3D Boat Show, Yacht Empire and Healthy Crew, are at ocean1.vc/apps.