The five-minute app

A few weeks ago I needed to process handwritten notes. My daughter’s school sends home worksheets, I jot things in notebooks during meetings, and none of it makes it into my digital system. So I built a tool that photographs a page, uses Gemini’s vision model to extract the text, detects any drawings or diagrams separately, and inserts the whole thing into my Obsidian vault with the original images attached.

A year ago, that’s a weekend project. Probably two weekends once you account for the vision API’s quirks and the image cropping logic. Instead, I described what I wanted and had a working version before the end of the day.

I’ve been doing this a lot lately. Small, personal, specific tools that solve exactly one problem in exactly the way I want it solved. A French dictee app for my daughter’s homework. A standup generator that reads yesterday’s daily note and drafts my update. A script that crawls my vault for external images, downloads them all locally, and rewrites every reference. An email triager that runs every six hours, classifies what landed, drafts replies to the important ones, and files the rest.

None of these are products. None of them are impressive. Most are under 200 lines. But collectively, they’ve changed how I work more than any app I’ve downloaded in the last five years.

The economics changed

I’ve always believed in building your own tools. The problem was the math. Even small tools have overhead: authentication, edge cases, the weird thing that only happens on your machine. A script that “should take an hour” takes four.

So you settle. You use the thing that’s 70% of what you want, because the last 30% isn’t worth a weekend. You adapt your workflow to your tools instead of the other way around.

AI inverted that equation. The overhead that made personal tools impractical, the boilerplate, the API wrangling, the fiddly UI code, that’s exactly what AI is best at. What’s left is the interesting part: deciding what to build and how it should work.

Katas that ship

There’s a concept in software called a kata: a small, repeatable exercise you do to build skill. Implement a sorting algorithm. Build a calculator. Parse some CSV. The idea comes from martial arts, where you practice the same form until it’s automatic.

I’ve never been able to stick with traditional katas. They feel disconnected from real work. You solve the problem, learn something, throw it away, and move on. The learning happens, but the artifact doesn’t matter.

Five-minute apps are katas that ship. You’re still practicing: scoping a problem, choosing an approach, making tradeoff decisions, iterating on something that doesn’t feel right. But the output is a tool you actually use. The handwritten note processor isn’t an exercise. It’s something I run constantly. The email triager isn’t a toy. It handles hundreds of messages a day.

This changes the feedback loop. A kata’s feedback is “did it pass the test?” A five-minute app’s feedback is “do I still use it three weeks later?” That second question teaches you things the first one can’t: whether your abstraction holds up, whether you scoped it right, whether the thing you thought was important actually was.

Traditional katas build mechanics. Five-minute apps build judgment. And judgment is the thing that’s hardest to develop when AI handles the mechanical work.

The practice

Building small tools regularly is a practice, not a one-time event. Like exercise, the individual session matters less than the consistency.

Each tool sharpens something. It forces me to think clearly about a problem. What exactly is annoying about my morning routine? What information do I actually need, and in what order? What’s the simplest version that would make me stop doing this manually?

That kind of thinking is the same muscle you use when designing products, scoping features, or evaluating architecture. You’re just applying it to yourself instead of a customer. And because the stakes are low and the feedback loop is immediate, you iterate faster than you would on anything at work.

I built a calendar app in Swift because I wanted a single view across my Apple and Google calendars(I understand this is not unique, but I have been using notion calendar, and I am migrating off all things notion at the moment). Not because I thought the world needed another calendar app. But the process of building it gave me real opinions about EventKit’s API design, about how natural language date parsing should work, about when a menu bar widget is the right UI and when it isn’t. Those opinions came from shipping, not reading. That’s the kind of knowledge that decays if you don’t use it.

What makes a good five-minute app

Not everything is worth building. The practice works when you’re solving a problem you actually have, not a hypothetical one.

My rough filter:

You do the thing manually more than twice a week. If you’re copying data between two apps, reformatting text, or running the same sequence of commands, that’s a signal.

The existing tools are close but not right. You’ve looked. Nothing does exactly what you want. You’ve been tolerating the gap because building felt expensive.

You can describe the whole thing in a few sentences. If you need a design doc, it’s not a five-minute app. You should be able to hold the entire tool in your head.

You’re the only user. This is freeing. No backwards compatibility. No edge cases you don’t have. No documentation. You can be as opinionated as you want because you’re the only one who has to live with it.

The compound effect

Each tool is small. But they stack.

My morning starts with a generated briefing: calendar, emails needing attention, open PRs, GitHub activity overnight, meeting prep notes pulled from my vault. That briefing feeds into a daily note. Throughout the day, tasks and links get captured into it. At the end of the week, a review generator reads all seven daily notes and writes a summary with completion rates and patterns.

I didn’t plan this system. It grew one tool at a time, each one solving a specific annoyance. But ten scripts that talk to each other become something larger than any of them. An operating system tuned to exactly how I think and work.

And unlike someone else’s app, I can change any part of it the moment it stops working for me. Last week I added semantic search across my entire vault because I wanted it. Took 5 minutes with qmd (thanks Tobi). Try getting that feature request prioritized in someone else’s product roadmap.

The new tools of the trade

There’s a second thing five-minute apps teach you that I didn’t expect: fluency with the AI toolchain itself.

Every tool I build is a low-stakes experiment with the new stack. Which models are good at what. When to use Claude versus Gemini. Where AI-generated code breaks down and where it’s surprisingly solid. What happens when you maintain AI-written code for a few months, which parts hold up and which quietly rot because nobody understood them well enough to write them by hand.

These are exactly the questions I need answered as a CEO deciding what to integrate at Pagecloud. What coding harnesses should the team use? Which MCP servers are worth setting up? How much should we trust AI-generated test coverage? Where do we need human review as a hard gate?

I could read blog posts and vendor demos to form those opinions. Or I could build thirty personal tools across six months and develop real intuition from actual use. The five-minute app gives you a test environment for the AI stack that no amount of reading can replace. You learn which prompting patterns produce maintainable code. You learn what “good enough” AI output looks like versus output that’s going to cost you later. You learn where the failure modes are before they show up in production.

The AI tools, the harnesses, the models, the protocols, these are the new tools of the trade. And like any tool, you don’t understand them by reading the manual, you understand them by building things(or at least thats how I understand them).

The real argument

I’ve written about taste. I’ve written about caring. I’ve written about how AI changes the cost of trying things. The five-minute app is where all of those ideas meet.

You build taste by making things and living with them. You demonstrate caring by solving problems others would tolerate. You benefit from collapsed costs by actually using them, not just talking about them. And you develop real fluency with AI tools by putting them to work on problems you care about, not by running demos.

If you’re a developer who hasn’t built something just for yourself in a while, try it. Pick the most annoying part of your day. Describe it to an AI. Ship something before dinner.

It won’t be impressive. It doesn’t need to be. The point isn’t the tool. The point is staying the kind of person who builds even if HOW we build feels like it’s changing every day.