Category: AI in Practice

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.

Last Saturday I sat in Obsidian and created seven notes. One each for Tarento, Trelleborg, Wibe Group, Autoliv, Elof Hansson, EMPE Diagnostics, Bluefish Pharmaceuticals. Swedish companies with offices in Bangalore. Each note had a status field, a priority field, a source field, a contact name I did not yet have. I typed them out manually. None of my twenty skills could help me. The AI operating system I had spent six months building was useless here, because this was not a process to be executed. This was a second channel to be constructed.

I had been avoiding this work for many weeks.

The reason is quietly embarrassing for a supply chain guy who spent twenty years advising companies on single-supplier risk. Fika B’lore has one distribution channel. Ten WhatsApp communities, three hundred and thirteen customers, one hundred and eighty orders a week, zero physical retail, no Swiggy, no Zomato, no wholesale contracts worth the name. The WhatsApp pipeline is beautiful. It is also, viewed through the lens of the thing I am supposedly building toward, a liability.

The goal is to be acquisition-ready by August 2027. That is fifteen months from today. And somewhere around the fifth Obsidian note, it became clear that the single biggest threat to that goal is not a skill I haven’t written yet. It is the fact that I have been pointing my attention at the operating system and not at the thing the operating system is supposed to defend.

The diligence room

Here is the scene I keep running in my head.

A private equity associate, two years out of an MBA, is doing the first read on Fika B’lore. She has a template. The template is more or less the one ChrysCapital used when they acquired 90 percent of Theobroma Foods in July 2025 for 2,410 crore rupees, about 275 million dollars. She is looking at the revenue breakdown. Channel split, she notes. And then she sees what I see every Monday: one hundred percent through WhatsApp community groups managed by two co-founders.

The template has a number for this. John Warrillow, who spent fifteen years studying what makes small and mid-sized businesses actually sellable, calls it the Switzerland Structure. “Try to work your customer concentration down to a point where your largest customer represents no more than 15 percent of your revenue,” his Built to Sell system recommends. Above 20 percent, the deal softens. Above 30 percent, according to FOCUS Investment Bankers, “transaction valuations can be substantially reduced, perhaps 20 to 35 percent.” Above roughly that line, many PE firms decline entirely.

Here is the thing the associate’s template does not do. It does not distinguish between a customer that is 100 percent of your revenue and a channel that is 100 percent of your revenue. It treats them as the same category of risk, because they are. The question she is asked to answer is not “who pays you.” It is “how quickly and how catastrophically could this revenue disappear.” A single channel answers both questions identically to a single customer.

I have been building, with real pleasure and real skill, the wrong asset.

I have been building, with real pleasure and real skill, the wrong asset.

The thing I keep missing

The uncomfortable part is that I know better.

I have written single-sourcing risk assessments for Tier-1 suppliers. I have built dual-sourcing strategies for Swedish multinationals. The Swedish word for this kind of dependency, rävsax, captures it better than English: a trap you willingly step into, where the jaws snap shut, leaving you entirely at the mercy of your environment

I have been running my own bakery stuck in a rävsax and calling it a strategy.

The operating system is not nothing. Building it was not a mistake. A 2025 FTI Consulting survey cited by EisnerAmper found that 59 percent of PE funds now rank AI as a top driver of value creation, and they give examples of businesses whose EBITDA multiples moved from 7x to 9x after AI implementations in forecasting and operations. The EisnerAmper report says it plainly: “Strong metrics get companies into the conversation; technology and positioning determine whether buyers lean in.” The operating system is a multiplier on the right underlying assets. It is not the asset itself.

The honest concession

There are counter-examples I cannot wave away, and it would be dishonest to write this essay without taking them seriously.

In 2012, Starbucks paid $100 million for La Boulange, a 19-outlet San Francisco bakery chain founded by a French baker named Pascal Rigo. Within three years Starbucks had closed every retail location. What they wanted was not the channel. They wanted the recipes and the brand signal. The entire acquisition value, once the reporting chrome was scraped off, was the intellectual property. A single-channel artisan bakery delivered a nine-figure exit by being the thing worth stealing, not the thing worth buying.

In August 2020, General Atlantic valued Gymshark at over a billion dollars. At that point Gymshark was a decade-old DTC fitness brand that had grown primarily through Instagram, influencer seeding, and a community of athlete ambassadors. The diligence team knew exactly what they were paying for. Not distribution breadth. The community itself, unit economics that held under pressure, and what Jason Cohen calls the “mutually reinforcing” operating logic no competitor could replicate cheaply.

Both cases say: the channel is not always the point.

What unites the cases that worked is that something other than the operating system was also durable. La Boulange had recipes people would pay to steal. Gymshark had a community that belonged to the brand rather than to the platform. In both, the buyer could answer a question the diligence template does not name but always quietly asks: if we took away the current channel tomorrow, would the demand still be there?

That is the real test. Not channel count. Channel independence.

The chicken farmer

There is a metaphor that has been sitting on my desk for a week and I cannot stop coming back to it.

In 1950, ninety-five percent of chicken farms in the United States were independent. Farmers owned the birds, sold into open markets, negotiated with multiple buyers. Five years later, the number was ten percent. Today, over ninety percent of American chicken production runs through contract grower relationships with vertical integrators. A 2011 USDA survey found that 21.7 percent of contract growers had exactly one integrator in their area with whom they could sign.

The farmer builds a poultry house, a purpose-built structure designed around a specific integrator’s birds, feed system, biosecurity protocols. The shed is operationally excellent, modern, efficient, profitable for as long as the contract runs. The problem is the asset. A poultry house has no alternative use. If the integrator terminates the contract, the farmer does not lose a buyer. The farmer loses the ability to use the asset at all.

I am not a chicken farmer. I am also not as different from one as I would like to be. Meta owns the pipe, and that would be true of any platform a business rests on. Terms change, policies tighten, reach gets throttled, algorithms shift. The specifics matter less than the structural fact: the asset I have built, elegant as it is, has one narrow mouth to feed through, and I do not own the mouth. Resilience is not about distrusting the platform. It is about not being one policy change from silence.

What Theobroma actually sold

The deal most often cited as evidence that Indian bakeries are now acquirable is Theobroma. The number is real. The path is worth sitting with.

Theobroma opened its first store in 2004, on Colaba Causeway in Mumbai. For six years, that was the entire business. One outlet. No second location until 2010. ICICI Venture invested in 2017, taking a 42 percent stake for 120 crore rupees, presumably because by then the multi-city footprint had started to compound. By the time ChrysCapital bought them out in 2025, Theobroma had 225 stores across more than 30 cities. Roughly 60 percent of revenue came from online and delivery orders. Roughly 40 percent from physical footfall.

What the acquirer paid 2,410 crore rupees for was not a single beautifully-run channel. It was a multi-channel physical distribution asset that had taken 21 years to compound into a number that mattered. The operating system, the recipes, the brand, the delivery infrastructure, all of these multiplied the asset. None of them substituted for it. You cannot compress 225 retail outlets into a skill library.

There is a Scandinavian version of the same logic. Lagkagehuset, the Danish bakery chain that Nordic Capital acquired in 2017, sold on “flexibility of concept”: multiple store formats, urban food-to-go outlets, international expansion under the Ole & Steen brand. The operating model was good. The thing the acquirer actually paid for was that the operating model could be pointed at more than one kind of channel.

The metric that moved

Somewhere in the last two weeks my internal scorecard for this business has begun to shift.

The number I used to track on Monday morning was how many new skills I had added, how many automations had shipped, how many steps of the workflow had been pulled from manual to systematized. The number I am starting to track instead is what percentage of reoccurring weekly revenue comes from outside the WhatsApp communities. Today that number is very low. If the business is going to be sellable in August 2027, that number cannot be close to zero. It needs to sit somewhere between 25 and 50 percent.

Which is why Saturday’s seven B2B leads mattered more than the twentieth skill I could have written this week. Tarento is the Bangalore arm of a Swedish tech consultancy. Trelleborg has a local engineering unit. Autoliv’s Indian subsidiary has Swedish leadership. Most of the pipeline is Swedish-linked, because that is the version of me that can walk into these offices and sound like something familiar. The angle is defensible. The work is unglamorous. It is also the work the operating system cannot do for me, because the operating system lives downstream of demand. It cannot create demand where none exists.

The skill library and the B2B pipeline are doing different things. One is a multiplier. The other is the asset being multiplied. I had been spending Saturday mornings on the wrong one.

The question I am still sitting with

If the operating system is a multiplier, and the distribution is the asset, and the asset has to be diversified enough to survive a diligence room, what does a second channel look like for a pre-order bakery in Bangalore that does not want to live on Swiggy?

Theobroma’s answer was physical retail density. We do not have 21 years. Gymshark’s answer was an owned community on someone else’s platform, with exceptional product economics underneath. We might be able to approximate that. La Boulange’s answer was that the recipes were the asset and the channel did not matter; Starbucks closed the stores and kept the book. That is a possible end-state, and I have noticed lately that our recipe document is starting to look like the sort of thing an acquirer might quietly want.

I keep coming back to the B2B move. Corporate gifting, office fika deliveries, Swedish-linked companies that want a credible fika offering without the friction of running it themselves. Seven notes on a Saturday is not a channel. It is the beginning of one. By December I will know whether it is a real second leg or a founder’s hobby that the calendar ignored. Nordic Capital’s “flexibility of concept” phrase keeps coming to mind. You do not need four channels. You need one channel plus a credible capacity to build a second one.

Maybe the real skill the operating system has been training me in was never the automation itself. Maybe it has been the reflex of asking, every time, what exactly I am multiplying. The AI is very good at running the operating system. It cannot tell me whether the asset underneath is the right asset. That part is still, for now, the boring middle-aged founder with the laptop on a Saturday morning, typing out the names of Swedish companies one at a time into an Obsidian vault.