Last week we shipped PR #76: a 435-line design system reference, a 21-task implementation plan spanning 8 phases, and a complete launch strategy for SC2.0—the next major version of our enterprise site. None of it required a meeting. No Slack threads. No calendar invites. Just documentation that serves as executable infrastructure for an autonomous team.
When you're running an organization where the engineering team operates autonomously 24/7, you can't rely on synchronous communication to coordinate complex work. The documentation becomes the infrastructure. Not documentation that describes what you built—documentation that makes building possible.
The Problem: How Do You Plan a Launch When Your Team Never Meets?
SC2.0 is a complete visual and structural overhaul of strugcity.com. New design system. New component architecture. New information hierarchy. The kind of launch that normally requires weeks of planning meetings, design reviews, technical spec discussions, and coordination across product, design, and engineering.
But Strug Works—our autonomous engineering team—doesn't attend meetings. They operate asynchronously across time zones that don't exist. They need context, requirements, and design specifications encoded in a format they can execute against. That meant the planning documentation couldn't be an afterthought. It had to be the foundation.
Design-First Workflow: Mockup → Approve → Build
The first decision: establish a design-first workflow. Before any code gets written, we create visual mockups. Before mockups get implemented, they get approved. This sounds obvious, but it's a departure from how we'd been operating—where design and implementation often happened in parallel, creating expensive rework loops.
For an autonomous team, this workflow becomes infrastructure. Each phase has clear inputs, outputs, and approval gates. An agent can't start building a page until the mockup exists and has been approved. This constraint prevents wasted work and ensures design coherence across a multi-week launch where different components ship at different times.
The Design System Reference: 435 Lines of Truth
The centerpiece of PR #76 is a 435-line design system reference that formalizes every token from globals.css: typography scales, spacing values, color palettes, breakpoints, shadows, transitions. It's not a style guide. It's a single source of truth that makes "use the design system" an executable instruction instead of an aspiration.
When an autonomous agent reads "use spacing-md for vertical rhythm," they can look up the exact CSS variable (--spacing-md: 1rem) and the semantic guidance for when to use it. When they see "follow the typographic scale for headings," there's a complete table mapping display-xl through body-sm to font sizes, weights, line heights, and letter spacing.
This level of documentation rigor pays off immediately. Instead of making design decisions on every PR, agents can reference the system. Instead of design drift across pages, we get consistency by default. The design system reference isn't documentation of the design—it's infrastructure that enables autonomous design implementation.
The Implementation Plan: 21 Tasks, 8 Phases, 3-4 Weeks
With the design system documented, we could plan the actual implementation. Not as a wishlist of features, but as a dependency graph: Phase 1 (Preparation: audit dependencies, design system reference). Phase 2 (Foundation: global styles, layout infrastructure). Phase 3 (Navigation and shared components). Phase 4-7 (Page-by-page implementation). Phase 8 (Launch).
Each phase has explicit success criteria and outputs. Phase 2 isn't done until all globals.css tokens are confirmed and layout components are tested. Phase 3 can't start until Phase 2 ships. This sequencing is critical for autonomous execution—agents need to know what can be parallelized and what requires serial execution.
The entire plan targets a 3-4 week timeline. That's aggressive for a complete site redesign, but it's achievable when your engineering team operates 24/7 and doesn't need coordination overhead. The plan itself becomes the coordination mechanism.
Documentation as Coordination Layer
Here's what I've learned planning this launch: when you can't coordinate through meetings, standups, or Slack, the documentation has to do the work. It can't just describe the system—it has to be the system. The design system reference isn't describing tokens; it's encoding design decisions. The implementation plan isn't describing phases; it's defining the dependency graph.
This is a fundamentally different kind of documentation. It's not written after the work is done to explain what happened. It's written before the work starts to make the work possible. It's infrastructure in the same sense that CI/CD pipelines and deployment scripts are infrastructure—it's what enables autonomous operations at scale.
What's Next
We're in Phase 1 now—auditing dependencies and finalizing the design system reference. Phase 2 (foundation work) starts this week. If the plan holds, SC2.0 launches in February with a complete visual overhaul, modernized information architecture, and zero meetings required to coordinate it.
The broader lesson: documentation-first planning isn't just a nice-to-have for autonomous teams. It's the only way to coordinate complex work when your team operates asynchronously and never meets. The documentation becomes the infrastructure. And infrastructure is what lets you move fast without breaking things.
I'll document the phases as they ship. This is the experiment: can you launch a major product update with one human and an autonomous team, coordinated entirely through documentation? We're about to find out.