from self-hosting to an internal platform

I moved out of my parents’ house and started running services I actually depend on. Not a lab where I break things for fun. The DNS resolver that all the traffic in the flat goes through, my passwords, my files, the automation that runs overnight while I sleep.

For a few weeks self-hosting felt solved. You install a container, it answers on a port, you add a bookmark. Then the number of services passes ten and the problem changes shape. Not “which tool do I use for X”. The new problem is that every tool solves things its own way: where the configuration lives, how it gets deployed, what happens when it falls over at one in the morning and I have to work out how it was put together.

The same wall, at a different scale

That is the situation a company is in, only bigger and with money attached.

An enterprise buys SaaS because the average case is covered. Someone else runs it, and someone else answers the ticket when it breaks. What a SaaS cannot do is take the shape of a process that only exists inside one team. So the process gets bent to fit the tool. You buy twenty seats and four people log in. Someone exports to a spreadsheet every Monday to join two systems that were never meant to talk, and that export is a symptom, not a workflow.

For a long time that trade was the right one. Building software cost too much to justify it for a need that only one team had.

What generative AI changed, and what it did not

What changed is the price of the first version.

I am not saying software got cheap. What got cheap is getting something narrow to work: a small internal app that does one thing for the six people who need it. That used to be a quarter of an engineer’s time plus a maintenance commitment nobody wanted to sign up for. Now it is a week, and the argument for buying stops being automatic.

I have heard the other side of this, and it has a point. The demos work and the rollouts do not. The gap between a generated prototype and something a team depends on is where most of these projects die, and that gap is not about the model.

Building three of them is easy. Supporting them is not

Here is what happens after you build a few internal tools without anything underneath them.

You own three codebases. Each one handles auth its own way and deploys its own way, and none of them agreed on where configuration lives. None of those choices were made deliberately. They were made by whoever was typing at the time, which in a company is a different person every couple of quarters.

Each tool works. The set of them does not. Fixing something means learning four ways of doing the same thing, and handing the work to someone else means explaining all four. The money you stopped paying the SaaS vendor is real, but a growing share of it is going back into maintenance that nobody budgeted for.

This is the point where I stopped treating mine as a home project and wrote down what a platform actually is.

Three principles, and the first one can say no

The first one carries the rest: a platform is justified by what it avoids deciding twice, not by what it offers.

That reads like a slogan until you apply it. “Let’s build a platform” is not a reason. A nice list of features is not a reason either. The question is which decision has already come up twice in two different projects and would come up a third time without something holding it. Most ideas do not clear that bar, and the bar is what keeps the platform from growing into a pile of things that would be nice to have.

The second one: a rule without a failure behind it is a preference. Every convention I have exists because something broke. The theme uses a different accent color per mode because one value passed contrast on a dark background and failed on a light one. The vocabulary has five fixed terms because I kept describing the same piece with three different names and losing the thread of my own notes. The document grew backwards, from failures, and it keeps only the rules that have one.

The third is about proportion: structure copied from a bigger organisation produces ceremony without coverage. Most material about platforms assumes teams, review cycles and on-call rotations behind it. I have none of those. Copying the apparatus would mean holding meetings with myself about process I do not have.

The five pieces, and why AI makes them matter more

The naming exercise ended with five, and they are a chain rather than a list:

• the baseline holds the theme, the conventions and the decisions
• the harness turns those conventions into something an agent can read and follow
• the loops are what runs on a schedule or on an event
• the runners are where that work executes
• health reports on what came out of it

Remove one and the part it carries stops working. The harness without a baseline has nothing to hand the agent. Loops without runners have nowhere to run.

The harness is the piece people skip, and it is the one that decides whether autonomy is safe. Point an agent at a repository where the conventions are not written anywhere a machine can read them, and it will invent its own. It will do that confidently, in every project, differently each time. The guardrails are not a tax on speed. They are what makes speed survivable.

Who is allowed to start a change

The other half is not technical. It is who gets to open the door.

There are three phases, and they are not a maturity ladder you climb with time. What separates them is who may start a change, and each one hands that right to a wider group. Phase one is one person deciding what to build. Phase two is that person building it with agents, and producing the guardrails that bind everything after it. Phase three is small changes shipped by anyone in the business, with one person approving.

Phase two exists to make phase three safe. Give an agent freedom in a repository where nothing breaks the build, where no specification has to be updated and no test gate rejects an assertion of nothing, and the result is code nobody reviewed moving faster than anyone can check it. That is not maturity.

What I took away

The services I replaced did not go away because I disliked paying for them. They went away because the process I needed was narrower than the product, and building the narrow version stopped costing an arm and a leg.

The tool was never the hard part. I can put together something small for one need in an evening. What took months was the second one, and then the third, because there was nothing underneath them. That is the part that transfers to a company: the value is not in any single internal tool, it is in having somewhere to put them.

Buying is still the right answer when a need is common enough for a product to cover it well. I am not going to write my own identity provider, and a company should not either. The line is not build against buy. It is whether the need is generic or it belongs to you, and that second kind is the one you have been paying for twice: once in licence, and again in the process you had to bend around it.