The era of personal software
Something that keeps coming up over and over again, pretty much since LLMs started getting good at building things, is the idea of personal software.
The idea is that once models get good enough, the effort to create an app that suits your exact needs will be so low that it will eventually replace most traditional software and it will become a commodity.
com·mod·i·ty /kəˈmɒdɪti/ n. (pl. com·mod·i·ties)
- 1an article of trade or commerce, especially a product as distinguished from a service.
- 2something of use, advantage, or value.
- 3Econ. a good or service whose wide availability typically leads to smaller profit margins and diminishes the importance of factors (such as brand name) other than price.
I don’t believe we’re there yet but there are more and more people building their own personal tools that they use both at work and in their personal lives.
I recently built an app I’d call personal software, one that I use every single day and it even made its way to my homescreen. I thought it would be interesting to document the process from start to finish and write about it.

My homescreen with the app I built
The idea
I’ve been spending a lot of time in NYC recently and I’m walking around way more than I used to. I also started tracking my exercise and I wanted to create a place where information from all of my devices would be stored and displayed.
|
|
|
|
|
___|___ |
| | | ___
| | | |_|_|
| | _|_ |_|_|
| | |=| |_|_|
|\ /| _|=|_ | |
/:\ /:\ _|:::|_ | |_|_|
|:\ /:| _|:::::|_ | |_|_|
|:\ /:| |:|:|:|:| (^) |_|_|
|:\ /:| |:|:|:|:| ((^)) | |
____ /::\ /::\ |:|:|:|:| (((^))) |_|_|
|::::| |:::\ /:::| |:|:|:|:| <|:|:|:|> |_|_|
|::::| |:::\ /:::| |:|:|:|:| |:|:|:| ___ |_|_|
|::::| |:::\ /:::| ____ |:|:|:|:| |:|:|:| |:::| | | ____
____|::::| |:::\ /:::| |::::| |:|:|:|:| ___ |:|:|:| |:::| |_|_| |::::|
|::::|::::| /::::\ /::::\ |::::| _|:|:|:|:|_ |:::| __|:|:|:|__ |:::| |_|_| |::::|
|::::|::::| |::::\ /::::| |::::| ___ |:|:|:|:|:| |:::| |:|:|:|:|:| |:::| |_|_| |::::|
|::::|::::| |::::\ /::::| |::::|___ |:::| _|:|:|:|:|:|_ |:::| |:|:|:|:|:| |:::| | | |::::|
|::::|::::| |:::::V:::::| |::::|:::|____|:::| |:::|:|:|:|:::| |:::|_|:|:|:|:|:|_|:::| |_|_| |::::|
|::::|::::| |:::::::::::| |::::|:::|::::|:::| |:::|:|:|:|:::| |:::||:|:|:|:|:|:||:::| |_|_| |::::|
|::::|::::| |:::::::::::| |::::|:::|::::|:::| |:::|:|:|:|:::| |:::||:|:|:|:|:|:||:::| |_|_| |::::|
|____|____|_|___________|_|____|___|____|___|_|_____________|_|___||___________||___|_|_|_|_|____|It’s not exactly a ground-breaking idea and there are definitely apps I could’ve used, including Apple Health, that would do an okay job.
But none did exactly what I was looking for. I wanted a web app with a very specific design. I’ve also wanted to try PlanetScale (opens in a new tab) for a while now and this felt like the perfect opportunity to do so.
The structure
The app is quite simple since I already had all of the data on my devices. The remaining problem to solve was getting it from my devices into the app and figuring out how to display it.
iOS automatically syncs the data from your devices to the native Health app and allows you to export it, which is great. I was only interested in a small subset of that data and I wanted the export to be automatic, ideally at regular intervals.
I found an app called Health Auto Export (opens in a new tab) that lets you set up an automation and specify exactly what data you want to export. I set it up to export the workout and health data as JSON every hour.

I could’ve probably built this part too, but since it wasn’t the focus, it felt more reasonable to just let another app that specializes in this handle it.
The database
As I mentioned earlier, I wanted to use PlanetScale (opens in a new tab) for the database, specifically the $5 Postgres, since that would be a great fit for an app like this. I onboarded using the MCP server and let an agent set everything up. It was incredibly easy.
This is something I’m experiencing more and more when onboarding to new tools. I don’t really interact with the UI at all, the agent just uses an MCP to set everything up on its own.
It set up the schema and a script to backfill all of my historical data. The automation sends data to an ingest endpoint every hour.
The database has 5 tables: workouts, sleep and meals, samples for daily totals like steps and energy and ai_usage, to track the AI spend.
- workouts
- sleep
- meals
- samples
- ai_usage
AI Agent
After deploying the first version in about 30 minutes, I realized that in order to make this actually useful, I’d need to add meal tracking too. The easiest way to do that was to add an agent that can estimate the calories for each meal I add.
| Day | Food | Kcal |
|---|---|---|
| 10-29 thu | Tomato bagel from Apollo | 450 |
| 10-29 thu | Iced latte from Variety | 190 |
| 10-28 wed | Cheeseburger at Hamburger America | 650 |
| 10-27 tue | Margherita at Lucali | 1,200 |
| 10-26 mon | Steak over rice from Inday | 850 |
I built the agent with the AI SDK (opens in a new tab) and while it was extremely easy to set up, I quickly realized that it wasn’t what I wanted.
const result = streamText({
model: "anthropic/claude-haiku-5.5",
instructions,
messages: await convertToModelMessages(messages),
stopWhen: isStepCount(15),
tools: {
webSearch: gateway.tools.parallelSearch({ maxResults: 5 }),
logFood: tool({
description,
inputSchema: z.object({ day: mealDay, items: mealItems }),
execute: ({ day, items }) => addMeals(day, items),
}),
},
});Paying for extra AI spend when I already had multiple subscriptions felt silly and I figured I should just use those instead.
It was also obvious that having to open the app every time I wanted to log a meal wasn’t the experience I wanted. Getting accurate values from a cheap model like Claude Haiku 5.5 turned out to be pretty difficult too.
Instead, I added an endpoint so agents like Grok Bot, Claude or Codex can write to the table. They’re much better at estimating values and need no extra spend.
{
"items": [
{ "name": "2 bagels with cream cheese", "kcal": 620 },
{ "name": "2 turkey ham slices", "kcal": 60 },
{ "name": "2 mozzarella slices", "kcal": 160 }
]
}I created a bot called Health in Grok Bot and gave it a token so it can write to the database. I send it the meals I eat, it researches the values online and logs them through the endpoint.
It has the entire chat history too, which is useful when things get repeated or it needs context.
It also reminds me to take supplements, sends me insights from the past week and keeps an eye on long-term trends. It’s basically my health coach.
Design
When it comes to the design, I had a clear idea of what I wanted. I’ve been enjoying the markdown-esque aesthetic recently, so I wanted to do something in that realm. It also works well for charts and tables, which this app is full of.
At the top of the app the Today section gives me an overview of my daily stats, like how I’m doing with my calorie tracking and how many steps I’ve taken.
Below, there’s a GitHub-like activity section that shows me my exercises and Active Energy, Steps, Eaten and Sleep charts.
At the bottom of the page there are a couple of tables that show me the past 10 entries for each category with the option to see more.
The beauty of building personal software is that you can do anything you want. A health data gathering web app with markdown-esque design is not something I’d imagine would be high up on people’s desired apps list.
Finding ideas
Previously, only huge companies had the resources to build internal tooling for their specific needs, now it feels like anyone can do it.
It can be difficult to come up with what you should build though. You shouldn’t build just for the sake of building. If you’re unsure, I’ve found asking your agent to be a good starting point.
Based on everything you know about me, what software could I build for myself that I'd actually use every day? Look for things I do repeatedly, track by hand or keep asking you about. Suggest a few ideas. Be specific.
There’s an incredible amount of insight in your past conversations, especially things you’ve been doing manually or asking about over and over again.
For example, a lot of the skills I’ve built started off like this. I asked my agent what kind of things I was doing manually over and over again and then built skills to do them for me. I originally didn’t plan on publishing them and only did so later.
(opens in a new tab)
More examples
A few other projects I’ve built also started this way. I built oklch.fyi (opens in a new tab) because I needed a place where I could play around and test OKLCH colors. I only made it public later after seeing the demand on Hacker News (opens in a new tab).
(opens in a new tab)
Loading.dev (opens in a new tab) was the same. We built it, because we were tired of having to define the same spinners in multiple projects over and over again. We only made it public after we’d been using it in our projects for a while.
(opens in a new tab)
Same for design.interfere.com (opens in a new tab). We built it as an internal tool that helps us document and work with our design system and only happened to make certain parts of it public later.
(opens in a new tab)
Meniny is an iOS app that I haven’t shared anywhere before, largely because it’s only useful to a handful of people. It allows you to track namedays (opens in a new tab) and birthdays easily in a single app. I mostly built this for myself, my friends and my family.
(opens in a new tab)
There are a couple other tools and apps that I built recently that have made my workflow much better, some of which have actually helped with this article and I’ll be releasing those soon.
Conclusion
People have been building tools that solve their own problems for a very long time. When solving a problem you encounter, you have a deep understanding of the struggle and are passionate about the solution.
Before models got this good, my Health app would’ve taken me much longer to build and I probably wouldn’t have done it.
It wouldn’t have been worth the time and I would’ve used an alternative built by someone else that didn’t do exactly what I wanted.
When building for yourself, the way you build changes. You no longer need to make decisions that work for everyone and you don’t need the app to make sense to anyone else but you.
If I really like a color combination and it doesn’t exactly pass contrast checks? Oh well, I’ll just use it anyway. There’s no real risk to making that choice other than affecting my own experience.
It doesn’t mean replacing all your tools with custom ones, at least for now. I wouldn’t do a better job than the person who built Health Auto Export because I haven’t spent enough time thinking about the problem, nor do I want to.
Personal software is not a new idea. What changed is how accessible it has become. You can easily build something tailored to your specific needs, exactly the way you want it.
Just you and your experience, even if it’s a little weird.
More
If you enjoy articles like this and want to learn more, take a look at Interfaces, my design engineering magazine.
It’s where I share everything I know about building great interfaces. From animation and typography to performance and accessibility.