Every month I receive a PDF that I need to split into individual two-page documents, each one named after a date, a title, and a reference buried somewhere in the text. It’s a chore. Twenty minutes of clicking, every single month, forever.
For most of my career, my reflex would have been to open the App Store, find a PDF utility that does something adjacent, pay for it, and then bend my naming convention to whatever the developer happened to imagine three years ago.
Instead I described the job to my agent. Ten minutes later I had a tool that does exactly that one thing, names files the way I name files, and would be completely useless to anyone else on the planet.
That last part is not a defect. It’s the entire argument of this article.
The middle tier of software is quietly disappearing
For thirty years, buying software meant accepting a compromise, and we accepted it so consistently that we stopped noticing it was a compromise at all.
Custom development was expensive. So you paid for the closest generic tool and absorbed the difference: a naming convention that isn’t yours, a workflow that’s almost right, a feature list where you use four items out of forty and pay for all forty. The gap between what the tool does and what you need was your problem to close, usually by changing your own habits.
That arrangement existed for exactly one reason — engineering time was the scarce resource. It isn’t anymore.
When building a small piece of software costs a sentence, the notion of a reusable app loses its monopoly. The economics invert. Software used to be an investment you amortized across repeated uses by many people; it becomes a consumable, and the ultra-specific version — the one shaped precisely like your workflow — now costs less than the effort of adapting to the generic one.
Let me be clear: this doesn’t kill durable software. Obsidian isn’t going anywhere. Neither is my calendar, my task manager, or my code editor. What’s being emptied is the middle tier — the moderately-adapted little utilities we bought because bespoke was out of reach. Bespoke became free. The tools that survive are the ones at the extremes: the deep, stateful platforms that took years to build, and the disposable scripts that took minutes.
Everything in between is on borrowed time.
Most productivity apps are a prompt wearing a costume
Before building anything, there’s a cheaper move that costs nothing to try: check whether the app you’re about to pay for is doing something a well-written prompt doesn’t already do.
Someone ran a thirty-day experiment on exactly this — before opening any app, ask whether a chat can do the job. Twelve tools disappeared: brainstorming, note organization, email drafts, meeting summaries, task planning, writing assistant, flashcards, study plans, project planning, content ideation, SWOT analysis, decision support. Twelve apps, replaced by twelve prompt patterns. The uncomfortable conclusion is that the value of those products was mostly a structured prompt with an interface and a subscription wrapped around it.
The same logic runs one level up, in territory you’d think was safer. A developer was paying roughly $150 a month across a security scanner, a PR review tool, a hosted browser-testing service, a documentation add-on, and an SEO suite. In every single case he was using three or four features out of a dozen. Five free plugins, living inside the editor he already worked in, covered exactly that subset — not the whole suite, only the part he actually consumed.
That’s the reframe worth keeping. The math that justifies a subscription compares it to a hypothetical complete usage. The math that kills it compares it to the subset you actually consume.
There’s a caveat, and it’s the thing that separates this from lazy AI enthusiasm: a vague prompt gives you a generic answer that replaces nothing. The patterns that actually stood in for those apps impose an output format, numeric constraints, and a demand for pushback — flag the two riskiest parts, tell me what I’m avoiding. The durable skill isn’t learning a new interface every six months. It’s writing specific instructions.
Three levels of building your own
“Build your own tool” sounds heavier than it is, because it isn’t one thing. It’s a gradient, and most of what I use never leaves the first two levels.
Level one: the disposable prompt. No artifact, no file, nothing to maintain. Look at these notes, find every commitment I made yesterday, list them by priority. I use it once and throw it away. If the output turns out to be worth having again, I persist it one notch — an automation regenerates it every morning and I work inside the result rather than requesting it.
Level two: the skill. When the same request comes back a third time, I stop retyping it. It becomes a markdown file the agent can invoke. I wrote about this shift a while back — a prompt tells an agent what to do now, a skill tells it how to behave every time the situation repeats.
The ordering matters here, and it’s the part most people get backwards. Don’t design the automation cold. Run the task manually once, successfully, then ask for it to be encoded. The successful session is the specification. Automating it becomes a sentence rather than a project, and the agent already knows what “done” looked like because it did it with you moments earlier.
There’s a second discipline hiding in that ordering: don’t freeze too early. Iterate in manual prompts long enough to hit the edge cases, and only then turn the thing into a skill. A skill written on the first attempt locks in your worst guesses and makes them permanent.
Level three: the real tool. Sometimes the thing has to persist. It needs a window, a keyboard shortcut, state that survives a restart, behavior that holds up when you’re not paying attention. That’s a different category of work, and it’s where the cheap magic stops.
When a personal tool crosses the line: Lemonize
I know exactly where that line is, because I stepped over it.
Lemonize started as a personal problem, not a product idea. I was three tabs deep in something else when a good idea showed up, and by the time I’d switched to Obsidian, found the right note, and decided where the thought belonged, the spark had degraded into a fragment I typed out of obligation. An idea that strikes mid-task has a shelf life measured in seconds. Obsidian — the best knowledge tool I’ve used, local files, full ownership — never had a fast way in.
The reasonable move, by everything I’ve argued above, was to build myself a scrappy capture script and move on. A hotkey, a text file, done in an afternoon.
I didn’t do that. I decided to build it properly, and to ship it.
The moment I made that decision, every shortcut that makes personal tooling cheap evaporated at once. A scrappy script that mangles a note with an emoji in the title costs me four minutes of annoyance. An app that does the same thing on someone else’s Mac costs me a customer and a piece of credibility. So Lemonize got an actual expression of needs, a design reference before a single line of Swift existed, an MVP plan cut into phases with acceptance criteria, and a test suite that decides what’s true instead of my optimism. When Apple rejected the first App Store submission, that structure is what made the recovery fast — I knew precisely what the app did and why, because it was written down before it was built.
That’s the honest shape of the trade. AI made the building cheap. It did nothing to make the shipping cheap. I’ve argued this at length in why it’s so simple to vibe-code an app today, and Lemonize is the proof in both directions: the same tools that let me generate a throwaway PDF splitter over coffee also let me build a real product — but only because I stopped treating them like a slot machine and started treating the process like product management.
The interesting part is what happened after launch. A tool you built for yourself and then shipped has a strange property: your own daily use is the roadmap. I hit that shortcut a dozen times a day, and every rough edge I hit is a bug report from the most demanding user the app will ever have. Lemonize has grown well past the capture panel it started as — it now feeds Bear and DEVONthink as well as Obsidian, and is becoming a universal app.
Development hasn’t slowed down. There’s a version in the works right now that widens what the app can do by a considerable margin — enough that “capture tool” will start to feel like an understatement. I’ll say more when it’s ready and not before, because announcing features before they survive their own test suite is how you turn a roadmap into an apology.
The lesson isn’t that personal tools should become products. It’s that the two are different jobs, and the cost of crossing between them is entirely on the shipping side.
Build first, decide after
There’s a second-order effect I didn’t anticipate, and it changed how I make decisions more than it changed what I build.
The classic cycle invests heavily in upstream planning so that engineers only build what’s essential — because engineering time was the bottleneck, and building the wrong thing was expensive. When an agent builds nearly instantly, the logic inverts: build the thing, then decide whether it deserves to exist. The artifact of decision stops being a document and becomes a demo.
Saying no to something already built is dramatically cheaper than having specified something badly. I’ve killed features after seeing them work, and that judgment was better than any amount of arguing about them in the abstract. A prototype you can click collapses the loop between generating and observing — instead of reading a description of an interface, you use it, then ask for the adjustment in the same breath.
But the real unlock isn’t automating what I used to do slowly. It’s the class of tasks I never even considered doing. A project status page that rewrites itself every few hours was never worth the manual pain of rereading a channel and hand-updating a document, so it never existed. Now it does, and it’s more useful than any document I’ve ever written, because a reference document’s value is proportional to its freshness — and freshness was always capped by the human cost of updating it.
The richest automation seam isn’t what you did slowly. It’s what you never thought to do at all.
What about the trade-offs?
The user and the developer being the same person is doing enormous work. Creating an app is a fraction of the job — the rest is edge cases, side effects, and the bugs your users find before you do. That’s still true, and it’s the strongest argument against everything above. Personal tools survive it only because there are no users. When my PDF splitter chokes on a weird page, nobody loses a sale and nobody loses trust. I lose four minutes and fix it. That asymmetry is the entire license to be sloppy, and it disappears the instant anyone else depends on the tool. Hand a colleague your clever script and you’ve silently promoted yourself to unpaid vendor.
Trust moves from clicking to reading. A no-code automation shows you every step in an interface you can inspect without reading a line of code. A generated script shows you nothing until you open it. You can read it — but you have to actually do it, every time it changes. Replacing a visual automation with code doesn’t remove the need for trust. It relocates the burden from the click onto your own attention, and pretending otherwise is how people end up with scripts silently doing the wrong thing for six months.
Reliability is the feature nobody demos. Flashy functions win the comparison at purchase time. What decides whether a tool holds up is whether it still works at the exact moment you need it — the sync that finishes in under a minute, the editor that doesn’t stutter on a long document. A tool I built in twenty minutes has precisely the robustness of twenty minutes of work. That’s fine for a monthly chore. It’s not fine for anything in the daily critical path, and knowing which is which is the whole skill.
And the failure mode I have to watch in myself: tool-building as procrastination. The honest measure of a productivity system is not what it organized. It’s what it shipped — published, sent, finished. Building tools is deeply satisfying precisely when the real work is uncertain and uncomfortable to start; you get structure, control, visible progress, none of which a blank page offers. I have spent entire afternoons perfecting a script for a task I could have done by hand in ten minutes, and I’d be lying if I called all of those afternoons investments. The system was never supposed to be the output.
What I still pay for
So the sorting rule isn’t can AI produce this output? That question flatters the AI and tells you nothing. The useful question is: does this app hold state over time, or between people?
A chat window is extraordinary at compressing thinking — summarizing, structuring, planning, challenging a decision I’ve already half-made. It fails at three things real tools do without effort: remembering my habits without having its context rebuilt from scratch every session, acting autonomously in the world, and holding me accountable to a deadline or to another person. Delete the apps whose value was compressed thinking. Keep the ones that persist, act, and constrain.
That’s why my vault, my task manager, and my calendar aren’t going anywhere. And it’s why I still happily pay for a well-made utility — preferably once, not monthly. The pricing model reveals the architecture: a service carrying real recurring costs earns a recurring fee, while a local utility with no backend charging you every month is telling you something about its confidence in its own future.
I also ask the exit question before adoption rather than during the crisis. Software history is a graveyard — the permanence of any given tool is an illusion, and every acquisition replays the same anxiety. If this stopped working tomorrow, would I be stuck? belongs next to the feature list at selection time, not in the migration panic three years later.
The custom tools pass that test by construction, and this is the part I care about most. They’re plain files I own — a markdown skill, a Python script, a plugin in a folder. My workflow doesn’t live inside a vendor’s product; it lives in files that a different agent, from a different company, can read next year. Having spent hundreds of hours structuring my processes for AI tools, I want those processes to survive the tools. File over app was the right principle for notes. File over AI is the same principle applied one layer down, to the processes themselves.
Is this for everyone?
You need enough technical literacy to read what comes back and tell obviously-wrong from plausibly-wrong — the second category is the dangerous one, and no amount of prompting protects you from it. You need the discipline to keep personal tools personal, because the moment you hand one to someone else, every shortcut that made it cheap turns into a liability you now owe them. And you need to be ruthlessly honest about the procrastination trap, because there’s no manager standing behind you to notice that you’ve built a beautiful pipeline instead of doing the work.
If none of that fits, the cheapest level still works for everyone, and it requires nothing but skepticism: before paying for a productivity tool, extract the prompt it’s running. If the answer is user input plus a template plus some formatting, you already own the tool.
Conclusion
For most of my career, software was something I chose from a shelf. The only question available to me was which of these existing tools is least wrong for my situation?
That question is dissolving. The tool shaped exactly like my workflow — unmarketable, unreusable, worthless to anyone but me — is now the cheap option, while the generic app I have to bend myself around has become the expensive one. And on the rare occasion a personal tool turns out to be worth sharing, as Lemonize did, the path from one to the other exists too. It’s a longer path than the demos suggest, and it’s paved with acceptance criteria.
None of this made me a better developer. It made me a more demanding user, because no tool does this stopped being an acceptable answer.
AI didn’t give me better productivity apps. It ended my dependence on someone else having already imagined my problem.
What’s the small, stupid, specific tool you’ve been waiting for someone else to build? I’d be curious to know whether you’ve tried building it yourself — and what broke first.