Standing up a business or a physical site properly involves three layers.

  1. Build the site — equipment, connectivity, furnishings, supplies, security, handover, financing
  2. Build the operating playbook — statutory inspections, safety management, vendor contacts, cleaning, procurement rules
  3. Stand up the organization — roles, chains of instruction, reporting, authority, hiring, training, ways of working

The order matters. At minimum, (2) should be settled before you put people into (3). Otherwise the people standing on site have nothing to anchor their judgment to.

At the newly built data center I’m currently involved with, that order broke down. People arrived first, and operations began with (2) absent. On top of which I am in Tokyo, holding the (1) project manager, (2) playbook designer, and (3) site manager roles simultaneously.

This is a record of nine days spent holding that together with 12 harnesses — about 6,000 lines — written with Claude Code.

What happens when there is no playbook

The most frequent messages coming back from the site were of one particular kind:

  • “Something arrived that we didn’t know about.”
  • “They’re telling us an inspection is scheduled — we hadn’t heard.”

This is not an attentiveness problem on site. It is a structural one. Information from (1) — equipment and supplies head office ordered, maintenance contracts head office signed — is reaching (3), the people on site, without passing through (2): the receiving procedure, the vendor contact list, the register. The layer it should route through does not exist, so whoever receives it has to improvise every time.

And one more thing. My own load is high not because of capability but because of role overlap. Questions from three people on site, coordination with six vendors, and reporting to head office and the executive team all converge on the same person. Things that would never collide if (1), (2), and (3) were held by different people all land in one inbox simply because they are held by one.

The harnesses exist so that one person can carry that overlap.

What got built in nine days

Nine days of concentrated work: 12 harnesses, 6,118 lines, 153 commits. The breakdown:

  • Procurement and approvals — selecting supplies → filing a purchase request in the groupware → ordering through a corporate e-commerce portal → receipt → inspection → posting to the register. That whole chain is pushed onto machines up to the point of filing, with the request contents written as JSON
  • Maintaining registers — supplies list, key register, project schedule. All spreadsheets on the shared drive, touched by both site and head office, updated with a version check
  • Scheduling — reconciling several people’s free time and producing candidate slots
  • Expense filing — through to registering receipt-backed line items in cloud expense
  • Org chart generation — a definition file as the source of truth, with diagrams and docs emitted as artifacts
  • A portal — separately built (1,900 lines) to hold the permanent rules. Procedures, the vendor list, key and access rules, and awaiting-response cards live there, and it is the single source of truth the three people on site look at

For context, the record of this period runs to 3,502 lines in HANDOFF.md — the destination for “what is currently in motion” and “why we decided this,” which the next session reads before starting.

What running a site remotely actually looks like

This gets too abstract, so here is a real day. It was the kickoff day; I was not on site. Three items handled from Tokyo. All three went end to end — investigate, fix, respond.

A supplies list that hadn’t been updated (about 1h15m). From the site: “Three items arrived but they aren’t reflected in the sheet.” The only evidence was two screenshots of an order screen. I read item names and amounts from the images, fetched the supplies list with its version, confirmed the rows were absent, and separated the cause into two distinct failure modes. Added three rows, extended the reference range on the summary tab to follow, then re-downloaded and verified before replying.

At that point I left the inspection column marked “pending.” What the site had seen was a delivery history, not the physical goods. There had been an earlier case where someone read only the quantity column and wrongly concluded “shortfall,” and I did not want to repeat it. A harness makes handling faster — and precisely because it is fast, you need the discipline not to record something as verified when it isn’t.

Checking key tags and posting to the register (about 8 minutes). From the site: one photo of three keys. Read the tag numbers and labels from the photo, matched them against the assignments decided the previous day, confirmed all three agreed. Updated the register with a version check, and verified that all 15 embedded photos survived the save before replying.

What mattered here was that the register’s row number was 13 while the assigned number was 016 — because 013 was already in use for a different key. Had that reconciliation slipped, we would have had duplicate key numbers. With physical keys, fixing that after the tags are affixed costs vastly more.

Restoring login to the facial-recognition system (about 1h40m). A vendor response had been forwarded on, but the administrator account issued eighteen months earlier was inaccessible. I opened the account list in the handover package to identify the production URL and ID, confirmed that production and staging have separate URLs and that the password wasn’t in the handover package because it’s invitation-based. I actually opened the login screen to confirm the two-factor situation, then drafted and sent a request for a reset link, following the on-screen guidance.

The answer that came back — that additional administrator accounts are free — made the account-sharing plan we’d been considering unnecessary. Since the admin screen displays each authenticated person’s name, address, and phone number, being able to attribute operation logs to individuals matters a great deal.

None of the three would have closed that day without the harnesses making the registers safe to touch. Each would have been “call the site, confirm, fix it later” — half a day gone.

Report results as replaced operations and eliminated failures

I did not measure elapsed time before and after. So I won’t write “X% faster.” Instead, here is what is verifiable as fact.

Failures that stopped occurring:

  • Version clobbering on registers — the pre-overwrite version check makes erasing someone else’s edits structurally impossible
  • Duplicate numbering — the duplicate key tag was caught on the register side, before anything was affixed to the physical key
  • “I said / you didn’t” — messages to the site are now written to a file before sending. Nine days produced 59 of them, and what was communicated when is traceable
  • Wrong format for the destination — Markdown characters appearing literally in chat was fixed by making the output format a rule
  • Assumed timestamps — post times are now pulled from the API’s send time rather than recalled. Though I got this wrong once that same day and had to issue a correction. A rule doesn’t mean you never break it

Leaving that last line in, rather than deleting it, seems to me the point of keeping a record like this.

What isn’t working

The honest part.

  • The harnesses live on one local machine. Credentials are in environment variables and nobody else can run them. I am a single point of failure
  • Automation reaches least far at the external interfaces. Posting to externally shared channels and to certain chat tools doesn’t pass the permission model, and remains manual
  • Update rights on the portal haven’t moved to the site. The people on site still can’t correct the rules themselves
  • There is no measurement of efficiency. Without elapsed-time logs I can’t state the improvement numerically. If I were to capture it, the fastest route would be recording start and completion timestamps on the task-management side
  • And layer (2), the operating playbook, is still not filled in. What the harnesses absorb is load from (1) and (3); the work of building the playbook itself is still ahead

Generalizing the experience

A harness is not a substitute for (2). It is the scaffolding that buys the time to build (2).

When people have already entered a site with no playbook, there are only three roads: (a) let the site absorb it, (b) halt until the playbook is settled, or (c) have someone carry all of it manually until the playbook exists. Most launches end up at (a) or (c), and whoever chose (c) burns out.

What AI-driven development changed is that (c) can now be carried by a harness rather than a person. Twelve scripts in nine days is a pace the conventional “internal tool development” framing simply cannot produce. Because it couldn’t, (a) used to be the only real option.

There is one condition, though. Someone who can write the harnesses has to actually be standing in one of the three layers. Gathering requirements from outside will not produce this pace. What makes it work is that the person exercising the judgment can put it into code on the spot.

If you’re in a similar state on a site or business launch, which layer to address first depends on the situation. I’m happy to go into specifics in a conversation.