How My Company Runs From My Phone on Claude Code

There is no laptop in this story.

That is the part people struggle with. They picture a founder hunched over a screen at midnight. Mine runs off a box in a data centre and I check on it from my phone in the queue for coffee.

The device in my hand does not matter. The work does not live there.

Let me walk you through an actual day.

The morning brief

I wake up and the first thing I read is not email. It is a brief.

While I slept, the system wrote up what happened, what it did, and the short list of things that need a human. Not a firehose. A page. What shipped, what is blocked, what is waiting on me.

I read it the way you would read a good status update from a chief of staff who never sleeps and never pads the report. Then I make a handful of decisions and put the phone down.

That is the whole morning ritual. Ten minutes. The business has already moved before I have finished my first coffee.

Most founders start the day by deciding what to do. I start the day by deciding what to allow. It is a completely different job, and it is a far smaller one.

The box, not the laptop

Here is the bit that makes the phone thing possible.

The system does not run on my machine. It runs on an always-on Linux box in a data centre. That box hosts the AI agents, the scheduled jobs, and working copies of every repo the business touches.

It does not care if my laptop is shut. It does not care if I am on a train with one bar of signal. It does not care if my phone dies. The work is happening somewhere else, on hardware that is always awake.

My phone is a window, not an engine. I can open it, read the state, tap approve, and close it. The compute is remote and permanent. The interface is whatever screen I happen to be holding.

This is the unlock nobody mentions when they talk about building with AI. Put the operator on a box that never sleeps, and your own availability stops being the bottleneck.

Five lanes, not one queue

Work does not all go the same way. That is the mistake I see people make. They pipe every task through one channel, and the trivial stuff and the dangerous stuff move at the same speed.

I split the work into lanes by risk and shape. Roughly five of them.

The inline lane. Small, contained, reversible edits. Notes, memory updates, a one-line fix. These just happen. No ceremony, no review. If it cannot break anything, it does not need me.

The direct lane. Mechanical changes I have explicitly signed off on. A rename, a config tweak, a known-safe operation. It commits straight, with a pre-flight check, because the shape is boring and the blast radius is nil.

The async lane. Well-bounded work with clear acceptance criteria that an agent can go away and do on its own, then come back with a proposal I review. I describe the outcome. It does the work. I check the result before anything lands.

The live-preview lane. Anything I need to see with my own eyes before it ships. A layout, a page, a flow. It gets built in an environment I can open on the phone and look at, so I am approving the thing itself and not a description of it.

The deep lane. The heavy, architecture-shaped work that genuinely needs a human at a proper keyboard. Big refactors. Decisions with long tails. This is the small slice that waits for me at a desk, and it is a much smaller slice than you would think.

The point of the lanes is that risk and effort get matched to the right route. Trivial work never waits on me. Dangerous work never runs without me. Everything in between finds its own level.

Founders drown because they treat every task as equally important and equally urgent. It is not. Sort the work by how much it can hurt you, and most of it turns out to need nothing from you at all.

The overnight cycle

The favourite part is the one I never see happen.

Overnight, a scheduled run fires. I call it the dream cycle, because it does what your brain does while you sleep. It consolidates. It tidies. It lines up tomorrow.

It pulls the loose threads of the day into memory so nothing gets forgotten. It clears small debts. It drafts the next batch of work so there is a running start in the morning instead of a cold engine.

I go to bed with an open list. I wake up with a shorter one and a pile of drafts to react to.

You do not get this from a chatbot you poke at during the day. You get it from a system on a schedule that treats the night as working hours because, for it, they are. Time you are not using is the cheapest leverage there is. Most people leave it on the floor.

Approving instead of doing

Here is the honest description of my role.

I do not operate the business day to day. I built the thing that operates it, and now I mostly say yes or no.

That distinction is the entire game. When you build with AI properly, your job stops being execution and becomes judgement. You are not writing the post, you are deciding it is good enough to ship. You are not running the migration, you are deciding it is safe to run.

And there is one line I never move. Anything public, anything involving money, anything irreversible stops and waits for a human. The system does the work. A person signs it off. Always.

That is not caution for its own sake. It is the difference between leverage and a liability. An operator that can act without a check is not a productivity gain, it is an incident waiting for a date. Keep the human on the decisions that bite, let the machine have everything else, and you get the speed without the cliff edge.

What this actually feels like

It feels quiet.

That is the strangest part. There is no frantic switching between twelve tabs. There is no 11pm repo housekeeping. There is a brief in the morning, a few taps through the day when something wants a decision, and a system that keeps moving whether I am watching or not.

I am not busier because I build with AI. I am less busy, and more is getting done. Those two things are supposed to be a trade. They are not, if you build the operator instead of becoming it.

If you want to try this

You do not need my exact setup. You need three ideas.

Put the operator somewhere that never sleeps, so your own availability is not the ceiling. Sort your work into lanes by risk, so the safe stuff never waits and the dangerous stuff never runs alone. And redefine your own job as approval, not execution, so the only thing you spend your attention on is the decision that actually needs you.

Do that, and the device in your hand stops mattering.

The business runs on the box. I just tell it what it is allowed to do next.

From my phone, usually. In the queue for coffee.