Personalization
You don't need to build an app. You need to change one.
Almost nobody wants software nobody has written before. What people actually want is the app they already like, with the one thing it does not do. Personalizing an open source app gets you that in a sentence, and leaves the rest of it — the part that works, and the people maintaining it — exactly where it was.
Web and Android · Your own database · Cents a month
From the store — for example
Recipe Box
Open source. Already works.
You say
“Add a shopping list that groups everything by supermarket aisle.”
Yours
Your Recipe Box
Your changes, your recipes, your database.
And it keeps up. When the original gets a fix or a new feature, it arrives in your copy — your changes stay put.
Why this beats building
Four fifths of the work was already done by somebody who cared about it.
- You are not building from scratch
- The expensive part of having your own app is the first version — the schema, the auth, the hundred screens nobody demos. That part already exists and already works.
- You still mostly use your favourite app
- A personalization is a handful of files, not a rewrite. Ninety-nine percent of what you run is the app you already chose, behaving the way you already know.
- Somebody else keeps the core alive
- The upstream maintainers go on maintaining. You are not inheriting a codebase; you are adding a detail to one that has a community around it.
- Personalizing is cheap enough to try
- You describe the change in a sentence and it runs for cents a month, so the idea does not have to be worth a project before you are allowed to have it.
Worth extending
Apps in the store that people actually personalize.
The catalogue is small on purpose — every listing is an app we have run ourselves. These are the ones where a small change is the difference between nearly right and yours.
Fork maintenance
Somebody else still maintains the app. You maintain the few details that are yours.
That is the whole bargain. A fork on GitHub is a copy that starts rotting the moment you make it; the reason personalizing an app is normally a bad idea is that you have just volunteered to maintain all of it. SproutOS runs the reconciliation for you, so the surface you own stays the size of the change you asked for.
Upstream
The original app
Its maintainers keep shipping fixes and features, the way they already were.
Your copy
Your personalization
The handful of changes you asked for, on top.
One of three things happens
Up to date
Nothing changed upstream. The run costs a few seconds and stops.
Merged
Upstream moved, your files were not in the way. The change lands in your copy and your project redeploys.
Conflict
Upstream and you changed the same lines. You get a pull request to resolve — not a silent overwrite, and not a stalled fork.
- You pick the cadence
- On every upstream release tag, or daily, weekly, or monthly. A missed interval stays due, so a quiet week catches up rather than skipping.
- A conflict is not a failure
- It is the normal state of a fork somebody is actually using. Only genuine failures count against the pause.
- Five failures in a row pauses it
- Every run costs money — tokens on a metered key, or wall-clock on a runner. A fork whose upstream has diverged past reconciliation would otherwise fail identically every night forever.
- It runs on your model
- The Claude Code subscription you already pay for, your own API key, or an in-house host. The upkeep is ours; the tokens can be yours.
On the web
The web store
Every listing, forkable from the browser. You can look around without an account — signing in is what it takes to make a copy, not to read the shelf.
On Android
The Android client
A public catalogue and your own apps in one place, with the websites you have deployed alongside them. Not on Google Play — the download page shows the checksums and walks through the permission Android will ask for.