There's a funny kind of tiredness that comes from building software for other people all day.
Not bad-tiredness (I love my job), but the specific weight of writing code that has to work for users you'll never meet, edge cases you'll never hit, and stakeholders whose priorities aren't yours. You spend your days making things robust, accessible, observable, scalable, documented, tested, reviewed, deployed, monitored, and "on-call"-able.
Then you go home, and you might want to write some code for yourself.
And the muscle memory kicks in. You start sketching out a config system. You think about how someone else might want to use it. You wonder if you should put it on GitHub with a proper README. You write tests for the thing you built in twenty minutes for an audience of one. You wonder to yourself: is this going to make me a millionaire? Is it worth the time and effort?
And hyper personal software is an idea I've been forming to help release me from this trap, and find new joy and love for the software I write for myself.
What is hyper personal software?
Hyper personal software is custom software you build for yourself, to solve your own specific problems, with no compromises and no audience.
It it was an emoji it would be 🦛, and if it was an abbreviation it would be HYPS (pronounced "hips").
It's not explicitly open source software (though it can be). It's not a side project that might one day be a startup (though that wouldn't hurt). It's not portfolio content (though it can help).
It's the digital equivalent of cooking yourself dinner. Not takeaway, not from a cookbook, just food you wanted to eat yourself, built with the skills you have.
Maggie Appleton has written beautifully about home-cooked software, framing it as a movement for the people just below the professional tier — the "barefoot doctors" of computing. People with enough skill to build small tools, but not enough to make a career of it.
I want to argue for the inverse.
Hyper personal software is what happens when professionals deliberately focus down. When senior+ engineers, the ones who know how to architect distributed systems and run incident reviews, decide to spend their evenings building something that will only ever have one user - themselves.
It's like a restaurant chef going home and making beans on toast for their kid, and finding that more satisfying than the tasting menu they have at work.
A combination of existing ideas
HYPS isn't a new idea.
It's an elegant dance of four overlapping movements that have been quietly converging for years:
- File over app — your data lives in plain files, not in someone else's database. Software is built on top of what is expressed in the files.
- Local-first software — your tools work without the cloud, and the web is an enhancement rather than a requirement.
- The small web (also called the indie web, the personal web, the web revival) — personal sites built by people, not platforms. Here you'll find incredible creativity and self-built websites, blogs, etc.
- Home-cooked software — apps built for specific households and families, not global audiences.
These all express the same underlying values:
- Ownership — your data, your domain, your files.
- Durability — open formats outlast proprietary ones. Plain text outlasts everything. Boring proven technologies over the newest fad.
- Sovereignty — no one else decides when your tools change, disappear, or start showing ads.
- Right-sizing — not everything needs to scale. A tool for four people is a success if those four people love it.
- Agency — building your own tools, tending your own garden, cooking your own meals, etc.
HYPS is what you get when you take all five values seriously and apply them to your own projects.
The manifesto
Here are my five rules for writing hyper personal software.
They're for me, but you can have them too if you like.
Build for yourself.
No compromises, no bloat, no unused features. No "what if someone wants to..." No extension frameworks. No plugin architecture. If you ever need it to do something else, you can extend it because you wrote it.
Forget the rules of professional software.
No tests unless you want them. No CI unless it makes you happy. No documentation beyond what you'll need in six months when you've forgotten how it works. No PR templates. No issue tracker. No roadmap. The pressure to make hobby code "correct" is the pressure that kills it. You don't even have to open source your work if you don't want to (though sharing is a delight).
Use simple technologies.
SQLite. Plain HTML. A Python script. The boring tools that have outlasted many generations of frameworks will probably work in a hundred years time. Unless you specifically want to play with something new - in which case, go ahead. The point is the choice is yours.
Store data in simple formats.
Markdown. JSON. CSV. SQLite. Because if your software breaks then you still have your data. If you rebuild it differently next year, there's no migration and your files just work with the new thing.
If you stop enjoying it, stop building it.
This is the most important rule. The whole point is the joy. The moment it becomes a chore then you've reinvented your day job. Let it go. Delete the repo. Start something else. The data was in plain files, so nothing is really lost.
What LLMs unlock for the professional tier
For the near-professional tier Appleton describes, LLMs are a force multiplier and they let people who couldn't quite ship a working app now ship one. That's wonderful, and it's also the framing every AI company is shouting about.
For hyper personal software, LLMs provide something different.
We don't need help writing the web server, or the markdown-to-HTML pipeline, or the database schema, or the OAuth flow. We've done those a hundred times. They're the boring parts. They're also the parts that, after a long day of work, are exactly the things that drain the will to keep going on a personal project.
LLMs can let us skip them. Hand them the solved problems and keep the interesting ones for ourselves. Spend the hour you have after the kid's in bed on the bit that's actually yours: the weird domain logic, the personal taxonomy, the specific workflow that only makes sense to you.
There's an environmental and ethical conversation to be had about this, and I'm not going to pretend it away. But on the narrow question of what LLMs do for hyper personal software, the answer is: they let tired professionals build the things they actually want to build, instead of stalling out on the third yak shave of the evening.
And like everything with the HYPS manifesto: if you don't want to use LLMs at home, that's okay.
Remember why you loved software
Most of us got into this because building things felt like magic. You typed something into a text editor and the machine did what you said. There was no product manager (no shade - I love you folks). There was no quarterly planning cycle. There was just you, the problem, and the satisfaction of solving it.
Somewhere along the way, that got lost. Not by anything villainous - just the slow accumulation of writing software professionally for a living. Standups, sprint planning, design reviews, RFC documents, post-incident reports, the constant distraction and "everything is a priority"-ism. All of that is necessary, and all of it is real work. But eventually you find yourself unable to see the joy.
HYPS is an opportunity to remember. To open a blank file on a Saturday afternoon and write something nobody asked for but yourself, that solves a problem only you have, in whatever way that works for you. To build things badly if you want, to cut corners, to embrace the rough edges, to over-engineer for the fun of it if you want to. To delete it on Thursday because you got bored. The work is its own reward.
The point
The point is sovereignty in the small. A handful of tools that are entirely yours, sitting on your own machine, reading and writing your own files. They won't get redesigned. They won't start showing ads. They won't pivot. They won't be deprecated by a Series B board meeting. They won't hold your data hostage when their pricing model changes. They'll do exactly what you wrote them to do, no more and no less, until you decide otherwise.
Every tool you build for yourself is one less subscription, one less account, one less platform that owns a piece of your daily life. That's worth something on its own. But the bigger thing is this: each one is a small reminder that you can still do this. That the magic is still there. That the machine still does what you tell it to, when you ask it nicely, in a language you've spent years learning to speak.
Go and write hyper personal software 🦛