A 30/60/90-day plan for rolling out Claude Code to a web team

A sensible Claude Code rollout for a marketing or web team runs in three stages. In the first 30 days, a small pilot group uses it on one or two repositories for a few repeating jobs, with written rules and a measured baseline. From day 31 to 60, you turn what the pilot learned into shared instructions, permission settings and a review process. From day 61 to 90, you measure the results and decide whether to expand, adjust or stop.

The point of going in stages is that Claude Code does real work on real files. It reads your codebase, edits files and runs commands, so the risks and the habits that control them are different from a chat tool. A pilot surfaces both while the stakes are small. Anthropic's own cost guidance makes the same recommendation: "start with a small pilot group" and establish a baseline "before wider rollout."

The plan below assumes your site's code is in git, you have a staging or preview environment, and at least one person can review a code change. If any of those is missing, fix that first, because a rollout without them is a rollout without a safety net.

Before day one: decisions to make

A few choices shape the whole rollout. Make them before anyone installs anything.

• The plan. Pro and Max are individual plans under Anthropic's consumer terms, and Anthropic's data usage page says it will train models on data from those accounts "when this setting is on". Team and Enterprise use commercial terms. Team adds single sign-on, central admin and analytics; Enterprise adds SCIM user provisioning and compliance features. Our Claude Code pricing guide compares every plan. Data questions for client or regulated work are a matter for your counsel, not this article.
• The pilot group. Two to four people who do the target work every week, including at least one who can review code.
• The repositories. One or two, ideally a marketing site or a content pipeline with a working build and a preview environment. Not the checkout flow on day one.
• The task types. Two or three repeating jobs, such as updating facts across pages, fixing titles and meta descriptions, or building landing pages from an existing template.
• An owner. One person responsible for the rules, the settings and the day-90 decision.

The plan at a glance

Days 1–30: the pilot

The first month is about learning what works on your site without putting it at risk.

1. Record the baseline. For each task type, log hours per task and time from request to live for a couple of weeks. If the pilot starts sooner, use recent tickets, but say so in the results.
2. Set up seats. Add the pilot group to your Team or Enterprise organization and turn on single sign-on if you use it.
3. Write a first project CLAUDE.md. Run /init for a draft, then cut it down to the commands, where content lives, the SEO rules that must not break and a short "Don't" list. Our guide to writing a CLAUDE.md for a website walks through it, and the templates page has copy-ready versions.
4. Add permission rules. A project .claude/settings.json that blocks reading environment files and pushing code. Deny rules apply in every permission mode.
5. Train the group. Anthropic's Claude Academy offers free courses, including "Claude Code 101". Add one internal session on your own rules: branches, plan mode, reading a diff.
6. Start small. Single-page changes first, then multi-page jobs once people are comfortable reviewing them.
7. Keep a log. Every time Claude does something unexpected, or someone types the same correction twice, write it down. That log becomes the next version of your rules.

During the pilot, every change goes through full human review, however small. People who don't write code can take part, but pair them with a reviewer. Our guide to using Claude Code safely on a live website covers the security side in detail.

Permissions and admin settings

Claude Code asks for approval before actions according to its permission mode. Anthropic's permission modes documentation lists several, from Manual, which asks before edits and commands, to auto mode, where a separate classifier model reviews actions in place of you, to bypassPermissions, which Anthropic says is for "isolated containers and VMs only" and "offers no protection against prompt injection or unintended actions." With Claude Code v2.1.283 or later, auto mode is the built-in starting mode for interactive terminal and VS Code sessions, so decide on purpose whether your team keeps it.

For a team, three controls matter most:

• Server-managed settings. On Team and Enterprise, Owners set organization-wide settings in the claude.ai admin console, and users can't override them. Anthropic's server-managed settings documentation says clients fetch them at startup and refresh them hourly.
• Block bypass mode. Setting permissions.disableBypassPermissionsMode to "disable" in managed settings stops anyone from skipping permission checks on company work.
• Choose the starting mode deliberately. Managed settings can set a default mode for the organization, or remove auto mode with permissions.disableAutoMode, if you want people to approve each action during the pilot.

Whatever you choose, don't switch off permission checks on a real site, and keep passwords and API keys out of prompts and CLAUDE.md.

Days 31–60: rules and review

The second month turns individual habits into shared defaults that don't depend on anyone remembering them.

1. Update the shared CLAUDE.md from the pilot log, through a reviewed pull request.
2. Move "must always happen" rules into hooks. A hook is a command that runs automatically at a set point, such as after every file edit. Anthropic describes hooks as deterministic, unlike CLAUDE.md, which is advisory.
3. Package repeated jobs as skills. A skill is a reusable instruction file for one job, such as an SEO check before committing, that Claude loads when it's relevant or when you call it.
4. Add automated PR review. Use Claude Code GitHub Actions, or Anthropic's managed Code Review, which is in research preview for Team and Enterprise. Our guide to Claude Code in GitHub Actions for website QA compares the two. Keep a person approving every merge.
5. Set spend limits. On Team plans, the seat allowance is the default ceiling. If you turn on usage credits, set limits at the organization, group or member level.
6. Turn on analytics. The Team and Enterprise dashboard shows active users, sessions and accepted lines. Connecting the GitHub app adds contribution metrics, in public beta.
7. Add a few more people from the same team, using the same rules and the same review standard.

If you connect outside tools through MCP servers in this phase, start with read-only or documentation servers and add write access later.

Days 61–90: measure and decide

The last month answers one question: is this worth expanding?

1. Measure the same task types the same way as the baseline: hours per task including review, time from request to live, cost per change and error rate.
2. Review errors after release. Look at every rollback, hotfix and bug traced to a pilot change. What rule would have prevented it?
3. Fill in an ROI worksheet with measured numbers only. Our guide to measuring the ROI of Claude Code includes a hypothetical worksheet and the claims to avoid.
4. Write the playbook. The rules, the settings, the review process, who owns what, and how new people get trained.
5. Decide. Expand to more people or repositories, adjust the rules and measure again, or stop. All three are legitimate outcomes.

After day 90: keeping it working

Claude Code ships changes every week, so a rollout is never finished. Review the CLAUDE.md files and settings every quarter, remove rules that no longer apply, and re-check plan details on Anthropic's pricing page before renewals. Keep the pilot log going as a team habit: every repeated mistake is a candidate for a new rule, hook or check. Anyone new joins the same way the pilot group did, with training on your rules and a reviewer on their first changes.

When not to roll out yet

• No git. Without version history, you can't review or undo changes reliably.
• No staging or preview. Every change would be tested on the live site.
• No reviewer. If nobody can read a diff, nobody can catch a bad change before it ships.
• No owner. Rules and settings drift without someone responsible for them.

In those cases, fix the foundation first or get outside help to set it up. If you hire someone, our rollout scope-of-work template lists what a rollout engagement should include.

Conclusion

A good Claude Code rollout is small, written down and measured: a pilot on real but low-risk work, rules and permission settings that turn good habits into defaults, automated review that never replaces a person's approval, and a day-90 decision based on numbers. The tool does real engineering work; your team still owns the decisions, the facts and the review. If you'd like help running the pilot, writing the rules or setting up managed settings and review, our Claude Code consulting service runs team rollouts. More guides are in our Claude Code Guide.

Frequently asked questions