Build Yourself a Software Kitchen

What's needed, in my view, is an ecosystem for durable, hyper-personalised, self-building software that improves over time. This would include a framework, standards and sharing capabilities for how AI agents build apps for you, how to maintain them, how apps integrate and how the useful parts are shared and reused.

Before getting into the specifics of the framework I propose for the above, I'd like to share my vision of what this would look like for an end-user.

Please meet Steve.

Steve has a finance app. It isn't a finance app that millions of other people also have. It knows he splits rent with two housemates, gets paid in two currencies, has three credit cards and is trying to spend less on eating out. It has the connections to pull data from each of his accounts, and even reconciles shared expenses with an API from the cost-splitting app he and his housemates use. Every Sunday morning, a short brief lands in his inbox: how his last week went against his budget, which expenses he forgot to put on Splitwise, and anything else worth flagging. On a monthly basis, it reviews his investment performance and flags any potential opportunities based on his preferences, and reminds him to follow up with his pension fund on the question he had last month. It notices that his internet bill has increased, and informs him that he can reduce this by negotiating with Virgin Media. He didn't configure any of this from a settings menu. He just described his life, and the app was built around the description.

He also has:

• A travel planning app that matches his style and process of planning trips around food.
• A leave planning app that is a simple calendar tracking his annual leave days and nothing more.
• A flight booking helper that also holds his points balances, knows he'll fly business on long-haul redemptions and not otherwise, and watches for the routes he actually cares about.
• A fitness app that knows his training history and goals.
• A small, almost silly, app that keeps track of when his housemates are travelling so they can plan dinners.

The apps are not islands. When Steve plans a trip, the travel app already knows what the finance app knows about his budget and what the flight planning app knows about his points balances. When he's hosting, the recipe app he scanned his family's handwritten cookbook into can hand a shopping list to his grocery list app. His blog-writing assistant can reach into the recipe app, pull the dish and its original photo, and help him draft a post about it. Nothing here required a company to negotiate a partnership or build an integration. The apps share one foundation.

Other people touch Steve's system too, on his terms. His accountant has a login and can see exactly the financial records they need. His optician and doctors' PAs email his medical records to a dedicated email address so his files get stored into his personal medical records repository. When he's planning a trip with friends who don't have systems of their own, they open a page he shares and see the itinerary and how much they owe him. Software works on Steve's behalf while he's asleep, and the people in his life plug into it effortlessly.

How did Steve get here?

He set it up on a Sunday afternoon.

In the first few minutes, the foundation stood itself up. The domain, the hosting, the storage, the database, the sign-in, and a core set of agents that run the place. Then Steve described how he wanted everything to look and feel: like my iPhone, he could have said, or like a comic book, or like an 80s news broadcast. That became the house style every app would inherit.

He told the architect agent he wanted to manage his money. The agent asked what he needed, suggested some ideas, and then went looking. There's a public shelf of app and module recipes that people around the world have published. Steve and the Architect agent talked through the options, from "deploy the popular one mostly as-is" to "build something fully bespoke." Steve picked the most-loved personal-finance app recipe, plus two add-on modules that fit him. For one feature he wanted, nothing off-the-shelf existed, so they sketched the design together.

He repeated the rhythm for travel and for fitness, mostly recipes, a little custom. For the housemate travel schedules app nothing on the shelf was close, so he spent an hour with the architect agent designing it from scratch in a back-and-forth where the architect facilitated and drove the conversation. While he went on a run in the park, builder agents assembled all his apps. By the time he was done with his post-run shower, all of his apps were ready, waiting for initial setup.

Things also keep moving without his input. When the recipes Steve built on get better, his builders pick up the improvements and offer them to him. He chooses which new features to take and bug fixes happen in the background. Because the architect agent knows his life and his taste, it occasionally surfaces something new that others have published: This seems like the sort of app you might like. Want it?

That's the end state: a suite of software that fits like a glove, that you own outright, that builds and maintains itself, and that works for you and the people you trust.

The authors I reference at the start of this piece have done an excellent job at articulating the case for this type of software. But for those unfamiliar, and to set the scene for what follows, below is my personal motivation for why I believe this ecosystem would be desirable.

It fits. Mass-market software is a compromise by definition. It's fast food. It has to serve millions, so it serves no one exactly. Software built for one person can drop every compromise. It's a home cooked meal by your mom, who knows you don't like peas. (Truly the worst vegetable.) The result isn't a marginally nicer app. It's a category of usefulness that previously couldn't exist. Most of the software a full life would benefit from simply doesn't exist, because the audience is too small to justify a company. E.g. the app that teaches you Bulgarian family customs because you're marrying into a Bulgarian family.

You own it. Today you rent almost everything. The apps you use today change their terms, raise their prices, introduce annoying ads, sunset the features you love, or shut down and take your data with them. In this model you own the stack. Nothing gets discontinued out from under you. Nothing holds your data hostage.

It's cheaper. When you pay for a subscription, you're covering the provider's compute and storage plus their staff, marketing, investors, and profit margin. Or you're paying with your attention and your data. Here you pay only for the underlying utilities: compute, storage, the model calls. Those are the same input costs every software company pays before adding everything else on top. Cutting out everything on top makes this permanently cheaper than a commercial alternative (except in investor-funded, loss-making pricing cases, which you'll be paying for later anyway when return on investment comes due).

No ads, no surveillance, no algo. There's no business sitting between you and your software with an incentive to monetise your attention. The only recommendations you get are the ones you asked to be built.

It's all connected. You can link together whatever you want. Your weight-loss tracker linked to your hiking planner linked to your recipes linked to your grocery order linked to your weight-lifting targets.

I studied economics, and still think of the world in those terms, so some charts will be involved. Bear with me here. Think of three things plotted against a single horizontal axis that runs from fully bespoke on the left to fully off-the-shelf on the right.

There's a clean precedent in MCP. Before MCP, every connector between an AI and an external tool was built from the ground up, every time. MCP gave that a standard, and the ecosystem of connectors exploded. This is the same move, one level up: a standard framework for building hyper-personalised software, designed so that there is maximum reuse and minimal waste.

The key insight is what gets shared. Even in the left-hand half of the spectrum, today, sharing software often means sharing finished source code. You clone it and run it as-is and any customisation is a new venture. But instead of shipping finished code, you can ship a Recipe: a structural skeleton with a reusable, semi-finished core, written from the start to be customised by an AI agent. A Recipe is never meant to run as-is. It's only a seed.

Crucially, its documentation isn't written for a human engineer to read. Rather, it's written for a builder agent to follow, including instructions on how to interview a non-technical person and turn their answers into their own version of the app. The repo is designed from the ground up to grow into a self-building app shaped to one person's exact needs, contrasting with today where the entire set of norms, culture, and tools (e.g. GitHub) has evolved around human engineers. This is how I imagine consumer open-source software to radically shift, from being built to be understood and deployed by human engineers with finite time and energy for customisation to being designed for AI agents to deploy.

This requires rethinking what software documentation even is. Every norm we have, READMEs, setup guides, API docs, assumes a human will read it and write the code. When the builder is an agent, a lot of those surfaces are obsolete and new ones are needed. CLAUDE.md and agents.md are the first signs of this shift.

The tools we have today, Claude Code, Codex, Lovable, etc. aren't enough on their own to reach "set up in an afternoon," because the norms and structures around how we build software mean they still rebuild too much from scratch. When I vibe-code an app, only something like 10–20% of the effort goes into building the core differentiating hyper-personal features. The other 80% is plumbing that's been built thousands of times before, plus the grind of standing up a tech stack every single time.

Which exposes the final point. For a public company, sharing one tech stack between a finance app and a recipe app would be madness. But these apps have a user base with 100% overlap of exactly one user (you). Running twenty separate tech stacks for your twenty personal tools is also madness. The sane design is one shared foundation that every app lives on. That foundation is the OS for your personal app ecosystem. Standing up a new app stops being an infrastructure project and becomes a pure act of building the one thing that's different. The distance from PoC to MVP becomes tiny.

So the need I see is for a standard, widely-adopted way of doing this that merges two concepts often at odds: the no-waste discipline of maximum reuse, and the freedom of fully personal software.

I propose Sanitude.

Sanitude is a Specification, not a company. There's no commercialisation layer, no platform fee, no one in the middle. You pay for your own tech stack and utilities, and nothing else. The Specification states what a system must provide to be compliant with the vision and principles I defined above, independent of any particular technology; alongside it sits a Reference Implementation, one opinionated (and very probably wrong-in-places) set of concrete choices, there to prove the thing can be built and to learn from for improving the specification. The rest of this section is the shape of that Specification at a high level.

The Kernel. At the centre is one shared foundation that every app shares: hosting and storage; a single communal database built on a shared ontology; identity and access control; definitions for how apps communicate; and a design system. Apps don't each bring their own foundation, they're rooms in one house, or meals in one kitchen.

Recipes. The unit of sharing isn't finished software, it's a Recipe: a customisable seed for an app, written from the start to be cooked by an agent into your version rather than run as-is. It's a flavour of open source code, designed to be easily plugged into an Instance of Sanitude. A Recipe describes what it offers (so an agent can judge whether it fits you), how to build it, how to check it still works after you've changed it, and how to implement its future updates.

The agents. A small central cast of agents does the work. An Inception agent stands everything up once. An Architect interviews you, designs your apps, and finds and suggests Recipes to use. Builders do the construction and apply upgrades. A Harmony agent keeps apps coherent as new ones join and ensures the kitchen is kept tidy. A Guardian watches security throughout. And a Curator publishes a private app of yours into a clean, shareable Recipe.

The lifecycle. Standing up the stack, provisioning, happens once, up front. After that, building an app is a conversation: you describe what you want, the Architect drafts a spec, the Builders realise it. Apps integrate by default because they share the foundation. Upgrades keep your existing code and patch it incrementally rather than regenerating it, and every change is reversible.

The Commons. Recipes are published and discovered in a shared registry built for natural selection: replication rewarded, forking and variation made frictionless, and fitness signals, what people actually use and what works well, deciding what thrives.

Put together, the day-to-day looks like this:

1. People publish Recipes, for whole apps or smaller add-on modules, that follow the standards.
2. You assemble your system from them, mostly off-the-shelf where good Recipes exist, custom where they don't.
3. Your apps share the foundation, so they integrate by default rather than by special effort.
4. When a Builder makes something genuinely new for you, the Curator can turn it into a sanitised, generic Recipe and offer it back, so the ecosystem grows every time anyone builds.

This is a classic network-effect flywheel: the more people build, the more Recipes exist; the more Recipes exist, the more of the cost–value space becomes "available"; the wider availability gets, the more people can build. The value of the network grows with the number of people in it.

But crucially, even without a network Sanitude has value. Compared to building a suite of personalised apps freestyle, Sanitude provides a faster, more structured and durable outcome even when building everything in isolation from the shelf of published recipes.

I have put together a very early v0.1 spec and outline of what a Reference Implementation could look like for Sanitude. You can read it here.

Unfortunately, even if my v0.1 spec for Sanitude was perfect, the full vision of "set up in an afternoon" isn't reachable yet because standing up the tech stack still needs a human. Someone has to create the accounts, wire up the keys and tokens, and connect the pieces. An agent can't do that end-to-end yet. Additionally, the building of the app would likely have to happen outside the app itself. Hooking up AI models inside the OS for building its own apps as described would require paying API rates for your frontier AI models and thus be prohibitively expensive. You'll still need to use Claude Code or Codex or whatever to build outside the app itself. So today this would realistically still be for the fairly tech-savvy, not yet for everyone. But for those people, it should lower the effort required dramatically for building a suite of personalised software.

I expect that the "set up in an afternoon" experience could probably only arrive once a service buys into this philosophy and offers an all-in-one foundation, the whole stack provisioned for you across hosting, authentication, database, storage, etc. and also acting as an aggregator for the AI models that both build and run your apps. But that service isn't this project, and I don't think it should come first.

There are also a few unresolved open questions that I need to answer. The first is the Ontology: keeping the nouns of a life coherent within a single Instance is doable, since the Harmony agent can arbitrate as new Apps join, but the promise of strangers' Recipes slotting together rests on a shared, canonical vocabulary. I'm not sure if the Harmony agent will be able to deal with the drift between Instances seamlessly or if a more mechanically robust approach is needed to ensure vocabulary stays coherent across Instances. The second is trust in regenerated code: because a Recipe is cooked fresh into every Instance, albeit along a trailblazed path, rather than imported as a finished dependency, I'm not sure the verify suites and Guardian would be trustworthy enough to gate code that's reaching into my bank account. The third is keeping the Commons safe from bad actors: a malicious Recipe could in principle be written to read as benign to the Guardian and still slip something past its tests. "An agent reviewing another agent's work" is a potentially fragile last line of defence. There might be some trade-off to be made between flexibility and security at some point.

Across all of these, one of the main themes is that I may be putting too much faith in the capabilities of the AI agents. But that is sort of the whole point of Sanitude. I try to answer the question, "Given these incredibly advanced and powerful models, what's the best way to organise them together to build software for myself?" And on the question of whether models are going to be good enough, I think the safe money is in the other direction. I think the likelihood is higher that this framework becomes obsolete, because a single model can "one-shot" everything, than the models not being good enough to achieve what I describe.

For now, I'm going to be working on standing up a fully fledged reference implementation of Sanitude to test out the Spec. It's mostly only theoretical for now, and I'd like to test drive it to see how it works in practice. I'll be making posts here on my site as I do so and sharing repos for the Kernel and recipes of apps that I've built.

Even if my specific take on this ends up a dud, I expect that what I describe may be the natural direction for things to be moving in, and we'll inevitably get there at the current pace. Whichever way things play out, I'm incredibly excited for what software will look like in a few years from now.