What 30 Days With Formaum Looks Like: Your Cowork Rollout, Day By Day

If you've landed here, you're probably evaluating whether a Cowork rollout is worth bringing in someone for, or whether your ops team could just install it and figure it out themselves. Fair question. Here's what actually happens in 30 days when we work together. So you know exactly what you're buying and what the process looks like.

No theory, no feature tour. Day by day, stage by stage, what your team sees and what you walk out with at the end.

Before We Start: Who This Is For

This rollout is built for a 2 to 5 person ops team running a multi-location or multi-stack operation. You've got knowledge locked in one or two people's heads. SOPs scattered across Google Docs, Notion pages, and the inbox of whoever onboarded the team three years ago. A stack of tools that don't talk to each other, so somebody on your team is the manual integration layer between them.

You've heard about Claude Cowork and Skills. You can see the shape of the opportunity. You don't have time to be the one figuring it out from scratch, and you don't want a strategy doc that hands the build to someone else. You want one operator to scope it, design it, build it, and train your team on it. That's what this is.

Stage 1. Discovery. Days 1 to 5.

Most rollouts skip this stage and pay for it in week four. Here's what actually needs to happen before any skill gets written.

What we figure out together:

• Where your operational knowledge actually lives. In whose head, in which doc, in which CRM nobody trusts.
• The 5 to 10 workflows that eat the most team hours every week.
• What automating those workflows would unlock. Capacity, revenue, sanity. We name the number.
• Your team's actual tool fluency. Not aspirational. Real. Who clicks where, who avoids what.
• What's already broken in your stack versus what needs to be built from scratch.
• Your calendar for the next 90 days. What's launching, what's high-stakes, what can wait.

I'm running this discovery as a production manager and an engineer at the same time. Most consultants will hand you a strategy doc and tell you to find someone to build it. I'm scoping the actual deploy in parallel, so by day 6 the architecture spec is something we ship against, not something you have to translate.

What you walk out with at the end of Stage 1:

• A written architecture spec. Which skills, which MCP connectors, which Live Artifacts, in what order.
• A failure-mode map. What breaks first if this goes wrong, what the rollback looks like, who owns the call.
• A timeline tied to your launches, not a generic template.
• A pilot workflow chosen by you, with a success metric we agree on before we build it.

Stage 2. Architecture. Days 6 to 12.

This is the week the deploy actually gets decided. Skills are easy to write. They're hard to write well. The gap between a skill that works in a demo and one that survives month two costs more in token spend and team frustration than the engineering hour ever does.

What gets designed with you, not at you:

• The skills your team will actually trigger. Not what looks good in a demo. The ones that match how your team already thinks and talks.
• Custom Live Artifacts for the things you check every day. Pipeline view, status board, financial summary, client status board. Live, not regenerated, not static HTML.
• A knowledge base structure that turns your scattered SOPs into trigger-able skills. Your existing docs are the raw material. We restructure them so Claude can use them.
• MCP connectors to whatever your stack runs on. CRM, calendar, inbox, accounting, project tool. If a connector exists, we wire it. If it doesn't, we scope a custom one in this stage so it ships in Stage 3.
• Failure modes, rollback paths, integration contracts. The unglamorous parts that determine whether your deploy survives the first month after handoff.

Once the schema, the failure modes, and the integration contracts are defined, the syntax writes fast. Most of the engineering value is in the design that happens before any code runs.

What you walk out with at the end of Stage 2:

• A schema doc your team can read. Plain English, not engineer-speak.
• A scoped list of skills, artifacts, and connectors with priorities and dependencies.
• A pilot plan. Which workflow goes first, who on your team validates it, what success looks like.

Stage 3. Build, Pilot, Iterate. Days 13 to 23.

This is the longest stage and the one most rollouts collapse into a vendor handoff. We don't. The build, the pilot, and the iteration loop run in the same week, with your team using what gets shipped.

What gets shipped:

• Cowork installed, configured, and tuned. The /customize step on every plugin. This is where 60 to 80% of the realized ROI lives, and it's the step almost every solo install skips.
• The first 5 to 10 production skills. Written, tested, version-controlled, and triggered by your team inside real workflows.
• Custom Live Artifacts deployed. Live data, not regenerated static HTML. Every dashboard reads from the source, not from a snapshot.
• Scheduled Tasks running for the recurring work. Daily briefs, status syncs, inbox triage, weekend pipeline summaries.
• One full workflow piloted with one team member, then handed to the rest of the team.
• A weekly tuning loop. Every skill that gets used gets logged. Anything that misfires gets caught and fixed in the same week.

Most agencies hand off a strategy. Most engineers hand off code. I hand off a deploy your team is already using by the time the engagement ends. The training during the build is what makes the handoff stick. People learn the system by running it, not by reading about it after the fact.

What you walk out with at the end of Stage 3:

• A working Cowork stack your team is actively using. Not a demo, not a sandbox.
• A pilot workflow validated against the success metric we agreed on in Stage 1.
• A ranked list of what to expand into next month. Skills to write, artifacts to build, connectors to wire.
• A token-spend baseline. What the stack costs to run, so the maintenance conversation in Stage 4 is honest.

Stage 4. Train, Handoff, Decide on Retainer. Days 24 to 30.

The last week is about making sure the deploy outlives the engagement. A system your team can't run without me is a failed handoff.

What happens:

• Team training. One to two live sessions, the whole team in the room. No slides. We walk through their actual workflows on the actual stack.
• A runbook. Written, version-controlled, owned by your team after handoff. Skill triggers, failure modes, escalation paths, who to call when something breaks.
• A maintenance cadence. Weekly 30-minute skill-load audit. Monthly 2-hour cost and performance review. Quarterly half-day architecture pass. So the stack doesn't drift the way most do at month three.
• Retainer decision. Most teams move to a maintenance retainer for ongoing tuning, skill expansion, /customize passes on new plugins, and integration work as your stack evolves. Some teams take it fully in-house. The runbook is built to support either path.

What you walk out with at the end of Stage 4:

• A trained team using the stack as part of their day, not as a side project.
• A runbook your team owns and maintains.
• A clear maintenance path. Retained or in-house, decided with full information.
• A decision framework for what to build next month, next quarter, next year.

Why 30 Days Actually Works

The reason 30 days hits is the discovery-first sequence. Most rollouts skip Stage 1 and pay for it in Stage 4, when the team can't use a stack that was never designed around how they work. By the time we ship the first skill on day 13, we already know which workflow it serves, which person on your team triggers it, and what success looks like.

The reason you'd bring in a hybrid operator instead of a strategist or a coder is that the deploy and the team-using-the-deploy are the same conversation. A strategist hands off a doc and disappears. A coder hands off a system the team doesn't know how to use. A production manager who also engineers hands off a team that's already operating differently.

You can pay tuition by figuring this sequence out the hard way. Most teams do. You can also bring in someone who's already deployed it across multi-location operations. The receipts are in production rollouts, not on this page.