A workforce of one

masad is a small software company that builds websites and systems for businesses. It has orderly work processes, review on everything it builds, and plans for what comes next. It has exactly one person in it, me. Most of what happens day to day is run by AI agents.

In practice it looks like this. Every task in the company opens as a work order and moves through fixed stages, specification, build, review. Each stage is worked by an agent with a defined role and written instructions, and no stage ends without an explicit outcome. It passed, it was rejected, or it comes up to me for a decision. Anything that touches the real world, money, a customer, something going live, stops and waits for my signature. The whole system runs on a small computer standing in the corner of my room, and most of the time I meet it through a daily briefing and the decisions waiting on my phone.

It matters to me to say what this is not. The AI does not manage the company, it runs it. Every decision that binds the company to someone else, and the responsibility for what comes out of it, stays with me. There is no magic here and no black box, there is a division of labor. The machine moves the work forward, a person decides.

Why build a company this way? Because in a company of one, that person's time is the resource that runs out first. I could have spent my hours writing code, and the company would have moved exactly as fast as those hours. Instead I spent them building a system that knows how to move without me, and to stop exactly at the points where it needs me. My hours now go where I have no substitute, judgment, taste and responsibility, and everything else keeps moving when I am not there.

It also matters to me to say where this stands. masad is young. Its first product has not launched yet, and its first customers are on the way. I could have waited two years with this newsletter and told the story backwards, once it was clear how it ends. But the things most worth writing about are happening now, in the middle, while it can still go wrong. An issue written from the middle is exactly what I would want to read from someone else, so that is what this will be.

What this will be is lessons from actually running a company like this. Some issues will go deep into a single story, a failure, an engineering decision, what it left in our hands. Some will be shorter and more immediate, what happened when we put a new tool or a new model to work here. Always from the company's own experience, never a news digest. And if this field interests you without a technical background, you are in the right place, the issues are written so you can take something from them without a single line of code.

The next issue is already written. It tells the story of one failure of ours, twenty hours in which nothing happened, and three principles that came out of it, relevant to any business with a process that waits for a person. If you would like to read it when it comes out, you can subscribe here on the site. I promise not to waste your time, and that is roughly the only thing we will promise in advance.