A few weeks ago I sat down with coffee and the month was already mostly closed. Overnight, something I had built had gone through the Razorpay payouts, matched them against the books in Odoo, reconciled the ones it could, flagged the three it could not, and left a draft of the GST export sitting where it knew I would look. I read it, corrected two lines it had reasonably misread, and sent it to the accountant. The part of the month-end I used to dread was twenty minutes of checking.
I am not a programmer. I have never been one. For twenty years my job was supply chain, which is a long education in other people’s systems, not in building your own. Fourteen months ago I could not have written a line of what ran that night. I still cannot, in the sense a real engineer would mean. And yet the thing exists, it runs on a schedule, and most of the time it is right.
I did not learn to code. The cost of not knowing how just fell to something I could finally afford.
Rosheden is the place I let myself show how, not only that, so let me describe what the thing actually is. The bakery and the consulting company and a rental house we keep in Sweden now run on a layer I assembled over the past year using Claude Code, which is Anthropic’s coding tool, driven almost entirely in plain English. There are around twenty-nine skills, which are just written instructions that teach the system how I do a specific recurring job: how we process the WhatsApp orders, how the monthly accounting closes, how a blog post for the bakery gets researched and drafted. There are sixty-odd memory files, which are facts it is not allowed to forget, our GST rates, our kitchen lease terms, the way one café wants its invoice discounted. There are connectors into Odoo, into Shopify, into the WordPress that hosts this essay, into Google Sheets, into the booking system for the house in Sweden, into Razorpay. There are thirteen scheduled jobs that wake up on their own and do work while I sleep. There is a live order form customers use. There is even a second agent, running on a different machine, that shares the same memory the first one uses.
None of that is impressive to a software person. I want to be honest about that before anyone else is. To a software person it is a pile of glue and configuration, the kind of thing a competent junior could tidy in a week. The thing that is worth an essay is not the system. It is who built it.
The make-or-buy decision
In supply chain there is a question you ask before almost anything else. Make or buy. Do you produce this thing yourself, or do you source it from someone whose whole business is producing it well. The default answer, drummed into you early, is buy. Buy the generic thing. Your own time is the one input you cannot reorder, so you spend it only on what is genuinely specific to you, and you let the market handle the rest. I have made that call a few hundred times in my career, almost always landing on buy.
What changed is not my judgment. It is the price on one side of the equation. For most of the work the bakery needed, there was nothing to buy. No vendor sells “reconcile a Bangalore bakery’s Razorpay settlements against its Odoo ledger and draft an Indian GST return for a business doing a hundred and eighty orders a week.” The market does not serve a business my size at that level of specificity. The off-the-shelf tools each solve a tenth of it and leave the seams to you. So the real choice was never make or buy. It was build it yourself, or do it by hand forever, or do not do it at all.
The cost of the first option used to be: learn to program, or hire someone who can, neither of which I was going to do for a bakery. Andrej Karpathy, who helped start OpenAI, said last year that English had become the hottest new programming language. That sounds like a slogan until it is your own week. The interface to building the thing turned out to be a language I already had, in the register I already think in, which is the operator’s register, not the engineer’s. I do not describe data structures to it. I describe the job the way I would describe it to a new hire who happens to never forget anything and works through the night.
That is the shift, and it is worth being plain about its size. The barrier was never that the software was hard to run. It was that building it required a craft most people do not have and cannot cheaply acquire. That barrier did not get lower. For a class of problems it briefly disappeared.
This has happened before
I want to resist the part of me that finds this historic, because it mostly is not. People who actually know the history of computing will recognise what I am describing, and they will not be impressed either, because they have seen it three or four times already.
In 1987 Apple shipped a program called HyperCard free with every Macintosh. The man who built it, Bill Atkinson, who died last year, described what he was doing as programming for the rest of us. And the rest of us did it. Teachers, nurses, librarians, people running small businesses built real working software in HyperCard through the late eighties and early nineties without ever calling themselves programmers. Before that it was the spreadsheet. VisiCalc, then Lotus, then Excel with its macros, and a whole generation of business people who built the systems their companies actually ran on while the IT department was still writing the requirements document. The field has a slightly dismissive name for it, end-user computing, and it has been studied since the mid-eighties. Every time the tools get accessible enough, the people closest to the problem stop waiting and build the thing themselves.
So I am not early to anything. I am a late and ordinary instance of a recurring pattern, holding a tool that is better at translating intent into working software than any of the previous ones, but doing exactly what the spreadsheet people did in 1990. There is a number that says I have company: the share of new companies started by a single founder went from under a quarter in 2019 to over a third by the middle of last year. Some of that is people doing alone what used to take a small team, because the layer underneath them does the work the team used to do.
What the history also warns
Here is the part of the HyperCard story that does not flatter me. Apple killed it. Through the nineties they starved it and then dropped it, and most of those systems the teachers and nurses had built simply died, because they existed only at the meeting point of one person and one piece of software. When either side went away, there was nothing left. The systems were powerful and personal and almost completely non-transferable. Nobody could inherit them, because the part that made them work was never written down anywhere except in the head of the person who built them.
I feel that risk in my own setup, and not theoretically. A few weeks ago the monthly numbers came out wrong because a product had been renamed in one place and not another, and the system, asked to match them, quietly valued a whole line of cookies at zero rather than complain. Another time an end-of-day rush of edits overwrote rows that had been added by hand, because the instruction I had written assumed the sheet looked the way it did when I wrote it. Each of these is my fault, not the tool’s. That is exactly the point. The thing runs beautifully until it does not, and on the day it does not, the only person who knows where it bends is me.
There is research now putting harder edges on the unease. A controlled study last year took experienced developers, gave them modern AI tools, and found they worked nineteen percent slower than without. The detail that stays with me is not the slowdown, it is that the same developers were sure they had been faster. They felt the speed and the speed was not there. I think about that every time I admire my own setup, because I cannot fully audit the feeling. I do not know how much of “this saved me a day” is true and how much is the satisfaction of having built it.
And then there is the question underneath all of it, which is the one I actually care about. We are trying to make the bakery something that can run without me and Niklas in the room, because we both intend to be living in Sweden in a year or so. The entire reason I built this layer was to get the operation out of my head and into something that survives me leaving. But a system that only I can operate is not the business running without me. It is me, wearing a more elaborate coat. The thing I built to remove the dependency may have become the dependency. A buyer doing their homework would see it in an afternoon, and an honest one would call it key-person risk, not an asset.
The jig
The closest thing I have found to what these skill files actually are comes from woodworking. A jig is a small tool you build in order to build the real thing. You make it once, it holds a single decision in place, the angle of a cut, the spacing of a row of holes, and from then on you do not have to make that decision again or even remember why you made it. A working shop fills up with jigs over the years. They are not instructions. They are decisions, set in wood.
That is what a skill file is. Every one of mine is a judgment I made once about how some part of the business should be done, hardened so it happens the same way every time without me thinking about it. The trouble with a shop full of jigs is that whoever inherits it gets the jigs but not the reasoning. They can see that this one cuts at this angle. They cannot see the afternoon you ruined three boards learning why it has to.
So the handover problem I keep circling is not really about software at all. The procedural part, the part you can write down, transfers fine. It is already written down; that is what the whole layer is. What does not transfer is the part that was never in the files in the first place. Which community is actually going to buy and which is just being polite. When a supplier’s cheerful confirmation at night means nothing about the morning. Whether the rate we are paying has a layer hidden in it. I have spent a year moving everything I could name out of my head and into a machine made entirely of named things, and the longer I do it the clearer the residue gets. The stuff that will not go in is the stuff that mattered most.
I do not know yet how much of me is in the jigs and how much is still just in me. I keep telling myself that if I write enough of it down, enough of the judgment will stick to the walls of the thing for someone else to run it. That might be true. It might also be the same comfortable feeling those developers had, certain they were faster while the clock said otherwise. In a year, when I am in Sweden and someone here opens the shop in the morning, I will find out which. Until then I keep building jigs, because it is the only part of the problem I know how to hold.