I have a draft blog post called “I Built a Startup in 28 Days for $120.” It’s a victory lap. First commit May 26, 1,286 commits later I had DeployMill, a working deployment platform where Claude wrote every line and my job was writing tickets, defining products, and testing. Total spend: a Claude Code subscription and two domains.

I never hit publish though. I kept dogfooding instead, and over the next month the platform taught me something that made the victory lap feel premature: I built the wrong thing.

Not a broken thing. DeployMill works really well and the beta testers love it. I run a dozen of my own apps on it right now, and the platform hosts 54 apps and counting, including the games my kids play and the CRM I put together for a friend’s business. The wrong part is what I thought the product was and what it was solving.

What I thought I was building

The original itch was simple, I wanted my agents to deploy code, preview it, read the logs, roll it back, and try again without me in the loop. Nothing on the market did that well, so I built it for myself. Deploy, preview, promote, rollback. When I got the first MCP server up and that loop worked it was magical so I continued. I added more, and more, way too much and lost focus.

What dogfooding actually showed me

Here is the pattern I saw over and over across a dozen apps and onboarding friends.

The deploy was never the hard part. Claude pushed code and the pipeline shipped it in a couple of minutes, every single time. What ate my time was everything around the deploy. A DNS record in Caddy pointing somewhere stale. One app had a secret its preview didn’t. The database backup I had technically configured but never once restored looked correct on the surface but was only a few kilobytes on disk. And a container that was healthy according to the health check and broken according to actual users.

When one of those things went wrong, the agent was mostly blind. It could see the slice of the world I had wrapped in a tool — this app, this deploy, these logs. It could not see that the DNS change and the failed deploy and the weird log line were the same incident. I could, because I had multiple browser tabs open. The agent had small keyholes into the system, I had the entire view which felt backwards.

That is when the framing flipped. Building software is close to free now. Between Lovable, Claude Code, and everything in between, a working app costs a night or weekend. What still costs real money, or a founder’s sleep, is operating that software once real users depend on it. Backups that probably restore. Rollbacks that also move traffic. Knowing what changed at 3am and why.

I had spent 28 days building a better deploy button. The actual gate between normal people and owning a software business is not deployment. It is operations. After 25 years of engineering, this has always been true but the speed at which code can now be written and “deployed” just makes it harder to ignore.

The most expensive lesson was circular

DeployMill deploys DeployMill, the best dogfooding story. In practice it means the platform’s own DNS, secrets, and cluster config sit inside the thing that can break them. When I wedged a core piece badly enough, the tool I would normally use to fix it was the thing that was down. I fixed it by hand, at the lowest level, the exact way the platform exists to make it unnecessary. Every time I had to open a terminal, DeployMill had failed.

The lesson: anything in the recovery path cannot be deployed by the platform itself. There has to be a boring layer underneath, deployed the dumb way, that never gets clever. I did not design that boundary into DeployMill. I found it by hitting it.

Everyone is retrofitting

Watch what the industry is doing right now and you see one move repeated everywhere: take human-first infrastructure and bolt an MCP adapter on top. An adapter over kubectl. An adapter over Terraform. An adapter over the Sentry or Datadog API.

Adapters will handle the easy 80%. Restart the service, bump the replica count, tail the logs. But an adapter inherits the shape of the tool underneath, and those tools were shaped for a human with dozens of tabs open and twenty plus years of context. Mid-incident, when the fix spans DNS and the deploy history and the database at once, the agent needs one coherent state model it can actually reason over. You cannot retrofit that. Logs, deploys, traffic, backups, and secrets have to be designed as one environment agents operate, not a row of keyholes they peek through.

That is agent native infrastructure. Almost nobody is building it, because the companies best positioned to build it have the most existing product to protect.

So, the pivot

DeployMill stays. It is my substrate and my proof, and honestly it is fun. But once the framing flipped, the obvious question was what I would build if I started from operations instead of deployment. The answer, agents operate production software end to end, humans supervise and own the business. The working name is Second Shift, because that is what it replaces. The shift you work after your real job, keeping the thing alive.

The short list of what has to be true: backups that prove they restore by actually booting. Rollbacks that are transactional, code and traffic together. Full structured logs an agent can query instead of grep. Hard levers, halt and rollback and revoke, that work even when the LLM provider is down. And a boring layer at the bottom that the platform can never take out with it.

28 days got me a deploy platform. It took another month of running real software on it to learn the deploy platform was the demo. What people will actually use is being able to trust the thing at 3am to run their business.

If you are already letting agents run things in production, or you want to, I would genuinely like to hear where it breaks for you!