Software gardens

You want a fitness app. Nothing that different from any other fitness app: It should track your reps, talk to your smartwatch, and nag you when you’ve gone quiet for a few days. The only difference is that you want the log button right on the home screen instead of buried three taps deep, because that one change will make you actually use it.

So at the end of the day, how much of your dream app is actually yours? Not the watch integration, the reminders, or certainly the database. Strip out all the commodity stuff, the features shared with thousands of other people who want roughly the same thing, and you’re left with maybe five percent that’s unique to you.

Right now, software treats that five percent as either too small to matter or large enough to justify rebuilding the whole thing. You can take someone else’s finished app and do without the part you wanted, or you can vibe-code the whole thing and reinvent the wheel, bugs and security holes included.

Coding agents change the economics of small differences. There should be a middle path that takes advantage of that change: software that is engineered around a stable core, but deliberately leaves room for user-shaped growth. I think of these as software gardens.

A garden is neither wilderness nor factory output. Someone prepares the soil, chooses what can grow there, lays out beds, sets stakes, prunes, waters, and weeds. Within those constraints, growth still has local variation. Plants lean toward light, fill available space, and respond to weather and care. The gardener has not authored every leaf, but they have designed the conditions under which growth is more likely to be healthy than chaotic.

Software gardens work the same way. A developer does not have to choose between shipping one finished app and handing the user a blank repo. They can build a scaffold: a stable structure with explicit places where variation is expected. To make that work, they have to answer three questions.

First: what stays fixed? Every useful app has core logic, data models, integrations, and safety boundaries that a user should not have to touch and, for the most part, does not want to touch. This is the foundation: engineered, maintained, and mostly invisible when everything is working.

Second: where is variation welcome? This is the range of shapes the app can plausibly take, because the developer made room for them ahead of time. Layouts might change, workflows might change, notification cadences might change. Payment processing, authentication, and parser internals probably should not. Explicitly dictating that range is what keeps customization from becoming arbitrary mutation.

Third: how does a user’s plain-language desire become working software? The answer might be a guided conversation with an agent, an implementation brief, a constrained code-generation process, and a test suite that has to pass before the change lands. This is the guided path from intent to implementation, without asking the user to become a software engineer.

Everything else is plumbing: the hooks a new feature attaches to, the tests that keep it functional, a coherent story for how the whole thing grows up over time.

To make this less abstract, imagine building a feed reader.

Let’s start with the part nobody should have to think about. Every feed reader needs to pull down RSS, parse it into something structured, and stash it in a database of sources and items. The app needs machinery to fetch things on a schedule and handle errors. None of that is where the app becomes your feed reader. The developer builds it once, hardens it, and it sits underneath everything as the foundation, the thing users grow on top of.

Next the developer makes a decision that shapes everything downstream: What is this app for? Let’s say they scope it as a news reader, and the range they want to support is mostly about rhythm and presentation. Some people want a single summary digest that lands once a day, while others want a live feed that updates in realtime. There’s a spread of formatting, cadence, and presentation choices in between. That’s the model for how much variation the app can support, but crucially, it’s only a model. The developer doesn’t build each one of these feed readers; they’re setting the limits of what their code can support. Tempo and layout, yes; rewriting how feeds get parsed, no.

So how does a particular user build something inside those limits? This is the part that wasn’t really plausible even a couple years ago, before competent coding agents. Instead of a giant settings panel or complicated customization language, the project ships a short guided conversation. An agent walks the user through questions that the developer identified as important to shaping the implementation: which sources you care about, how often you want to hear from them, whether you’d rather skim headlines or read summaries. The answers get distilled into a brief, and the agent uses that brief to build the user’s version on top of the foundation.

Underneath all of that is supporting technical plumbing. For any of this to work, the developer has to document the extension points: the data model for sources and items, the contracts the frontend relies on, the hooks a new feature can grab onto. A test suite ensures that anything the agent builds doesn’t quietly break core functionality. And there’s a looser forward-looking question: How do the scaffold and the things people grow in it evolve together over time?

Pull back from the feed reader, and a different development shape comes into focus. The developer did not build one app, and they did not ship a blank canvas. They decided which parts required full engineering control and which parts could be opened to user customization. Then they made those open parts accessible in plain language.

The software engineering expertise stays central. The user gets to adapt the tool to the way they actually work, described in the way they understand that work, without having to learn what a data contract is or why touching the parser is a bad idea. The AI sits in the middle and translates between the two. The scaffold is what keeps that translation from turning into a mess.

This brings us back to the person who just wanted the log button on the home screen. In a software garden, that is not a fork, a feature request that dies in someone’s backlog, or a weekend lost to vibe-coding a fitness app from scratch. It is a conversation with an agent, taking place on top of a solid software stack. They describe the one thing that is genuinely theirs, and they get it, grown on top of the ninety-five percent they never had to think about.

A software garden is one way to think about where engineering labor should go. The developer is not trying to predict every user’s workflow. They are building stable ground, dictating the places that can change, and giving agents a controlled way to make those changes. Leave that work undone and we will keep bouncing between generic apps that almost fit and one-off AI apps with shaky foundations. Do it well, and software can become personal in the parts that matter without becoming fragile everywhere else.