A few weeks ago I watched a small script rewrite my task list — reschedule three deadlines, mark two jobs blocked, cross-link a fourth to the work it was waiting on — and I realised I had not opened a task-management app in months. Not cancelled the subscription and forgotten about it. Actually stopped needing one.
That was the moment a slow experiment turned into a settled habit. Over the past year I have quietly replaced most of the software I used to pay for, and the replacements are almost all things I built myself.
I want to be careful here, because this reads like a productivity boast and it isn't one. The interesting part was never the tools. It is what the exercise taught me about the difference between buying a capability and actually owning one.
Start with what went, because the list is longer than I expected when I added it up.
The social-media scheduling tools went first — the ones that run your posting calendar for a monthly fee and send you a cheerful email when something publishes. The editor and coding tooling went next. Then a small stack of SEO testing tools, each with its own login and its own invoice. Then the task managers. My accounting system is technically still there, but it has quietly demoted itself: it is a compliance artefact now, something I feed at tax time, not a thing I open on a Tuesday.
Some of the replacements were not built from nothing. A few reused a skill I already had, or an open project on someone else's account that did eighty per cent of the job and needed the last twenty bent to my particular situation. Most, though, were built from scratch — because the specific need was mine, and nobody sells software for a market of one. They started small. A script that did one annoying thing, written because the annoying thing had happened three times that week, then extended when the next annoying thing turned up beside it.
The SEO tools are the cleanest example. I used to pay for several point tools, each doing one slice of the work, each reassuringly designed. They are all gone. A single data service now covers the same ground and covers it better, because I get the raw numbers and decide what they mean instead of paying someone else to decide and hand me a chart. The charts always looked calm and authoritative. That, it turns out, was most of what I was paying for.
The coding tooling is a quieter story with the same shape. I did not set out to replace it; I set out to stop being interrupted by it. Each add-on solved a real problem and introduced two small ones — a setting that drifted, an update that broke a workflow overnight, a renewal that arrived whether I had opened the thing that month or not. One weekend I wrote a handful of short scripts to do the three things I actually used those add-ons for. The scripts have never drifted, never updated themselves at an inconvenient moment, and never sent me an invoice. They are not better than the commercial tools in any way a reviewer would score. They are just mine, they do exactly those three things, and they do nothing else.
The task list is the one I keep returning to, because it sounds the least impressive and has proved the most useful.
I do not have a task-management tool. What I have is a set of plain text files — one per project — that record what needs doing, when it is due, and what it depends on. Nothing exotic. A person could read them without training. Some of them I have never once opened by hand.
The reason I have never opened them by hand is a small skill I wrote that does the editing for me. I tell it, in ordinary English, that a job is finished, or that it should slip a fortnight, or that it cannot begin until another job is done — and it goes and makes the edit. It assigns the identifier, sets the date, records the dependency, and works out that a blocked task should drop off today's list until the thing it depends on is marked done, then quietly reappear. When I ask what is due, it reads every file across every project and hands me one ranked list. When I plan a quarter, it stamps out the same shape of tasks from a template, so I am not retyping the scaffolding of good intentions every three months.
None of that is clever. It is a few hundred lines doing something extremely boring, extremely reliably. But it retired an entire category of paid software, and it did one thing the paid software never managed: it fits my situation exactly, because I built it around my situation instead of bending my situation around it.
Here is the part I did not see coming.
Building these things made me better at the underlying work, not worse. That runs directly against the usual promise of software, which is that you should not have to understand a thing in order to use it — that the tool exists precisely so you can skip the understanding. For a long time I believed that promise. A polished interface laid over a hard problem feels like a solution.
It mostly isn't. It is a tidy place to put the problem so you can stop looking at it.
When you build the tool yourself, even badly, you cannot look away. You have to know what "due" actually means to you before you can teach a script to schedule it. You have to understand what you are measuring before you can pull the raw number instead of the soothing dashboard. The physics degree I have never once used in a lab did leave me one habit worth keeping: a quiet suspicion of any box I cannot see inside. Building the box myself is the cheapest way I have found to see inside it.
I am aware this carries a cost, and I would rather name it than pretend it away.
The obvious one is time. Building a tool takes longer, at the start, than paying for one. If you need the capability this afternoon, buy it this afternoon and get on with your day. I am not arguing that every person should rebuild every piece of software they touch — that is its own kind of trap, and I have watched capable people disappear down it and never ship the actual work they set out to do.
The line I have settled on is roughly this. If the thing is generic, rent it. If the thing is close to what you actually do — the way you think about your own work, your own numbers, your own customers — then the standard product will always fit you like a suit bought off the rack for someone a different shape, and you will spend years quietly adjusting yourself to it without noticing. That is the expensive version. It just never arrives as a line item you can see.
Which brings me, at last, to the number — because I promised myself I would not open with it.
The single subscription I do pay for now, the one that makes all this building possible, costs about three hundred dollars a month. When I total up the tools it let me retire — the scheduling, the SEO stack, the task managers, the scattered odds and ends — it has replaced something in the order of eight hundred dollars a month in software I used to rent. So the largest software bill on my desk reads, in honest accounting, as roughly a five-hundred-dollar monthly saving.
But the money is the least of it, and if the money were the whole of it I would not have written any of this down. The real return is that I now understand the tools I depend on, because I made them. When one breaks I can fix it that afternoon. When my situation changes I change the tool to match, instead of waiting for a roadmap. Nothing I rely on is a black box I am renting from a company whose interests are only ever roughly aligned with mine.
So the question I would leave you with is not "what are your subscriptions costing you." That is the easy question. The answer is usually a little embarrassing and quickly forgotten. The harder one is this: of the tools you lean on every single day, how many could you actually rebuild if you had to — and what does it say that, for most of us, the honest answer is none?