How teams should roll out Cursor in the first 30 days

Buying Cursor seats for everyone on Monday is not a rollout.

It is a license dump. By Friday you have three invented folder maps, no shared rules, and PRs nobody can explain. That is not cursor ai for developers. That is a tool drop with no fence.

I’m Aris Setiawan. Senior full-stack, first Cursor Ambassador in Indonesia. I ship client work in Cursor every week. When a team asks me to “just turn it on,” I slow them down. Two or three people, one repo, shared rules, then expand.

The production loop is How to use Cursor AI to ship faster without wrecking the codebase. The daily habits are in How to use Cursor AI effectively on a real repo. This post is the team version: a 30-day plan that does not torch the codebase.

Why a big-bang seat dump fails

Cursor is not a plugin you sprinkle on a sprint. It writes code. If ten people write with no shared fence, you get ten architectures.

I still see the same three failures:

No fence. Nobody wrote project rules. Each person invents a folder, an error shape, a test command. Composer follows whoever typed last.

No review habit. People merge the summary. Extra files land. Helpers get duplicated. Tests stay skipped. I wrote the PR review checklist for AI-generated code because this is the first thing that breaks on a team.

Invented architecture. A new utils/ next to lib/. A second UI kit. A package nobody asked for. One developer can undo that. Ten developers do it in parallel.

If your first week is “everyone gets a seat,” you will spend month two cleaning up month one.

The first 30 days, in one picture

Keep the first month small. Shared rules. One repo. Review the diffs. Then expand.

That is the whole plan. Seats come after the habit, not before.

Week 1: two or three people, one repo

Pick people who already review PRs. Not the loudest. Not “everyone who asked.”

Install Cursor on that group only. Point them at one repo, the one you actually ship. Do not start on a toy app. Toy apps teach toy habits.

On day one, add project rules in git. Stack, folder map, do not create packages, error shape, test command. The long version is Project rules that stop Cursor from inventing bad architecture. Put the file in the repo so Chat and Composer both see it. A wiki page nobody opens is not a rule.

Split the tools. Chat plans. Composer (or Agent) ships a scoped diff. If you skip that split, people treat Composer like Chat with write access. I covered when I use each in Chat vs Composer in Cursor.

Week 1 success is boring: the small group can explain every file they merged. If they cannot, do not add seats.

Week 2: review the diffs, share the rules

Week 2 is not “more people.” It is the review gate.

Run the PR checklist on every Composer diff: blast radius, no new top-level folders, types match siblings, tests that already existed, secrets or payments only if the ticket named them, no “while we are here.” If a box fails, the PR is not ready.

Put the rules file on the same PR habit as code. When someone finds a new pattern (“we do not add utils/“), it goes in the rules, not in Slack. Slack is a rumor. Git is the fence.

Pair on one real ticket. Sit together, plan in Chat, ship a small Composer diff, review it out loud. That hour teaches more than a lunch-and-learn.

If the first group is still merging summaries, you do not have a rollout. You have a mess with better autocomplete.

Week 3 and 4: expand only after they can explain the diff

Add the next two or three people only when the first group can:

• Point at the rules file and say what it blocks.
• Review a Composer PR without rubber-stamping the summary.
• Split Chat (plan) and Composer (scoped write) without being asked.

Then copy the same loop: same repo, same rules, same checklist. Do not open a second repo “to experiment.” Experiments leak into prod.

By week 4 you want a short written loop the team owns: rules in git, Chat then Composer, checklist on the PR, revert extra files. If that loop is not written down, it will die the first busy week.

What not to do

Three moves that look fast and cost you a month.

Everyone day one. Ten seats, ten invented maps. Start with two or three.

No fence. If the rules are not in the repo, Composer will invent a stack. Write them before the second person joins.

Merge the summary. “Looks good” on a Composer recap is not review. Read the diff. Cut the extra. Split the work if it is 30 files.

I would also skip: a company-wide enablement deck before anyone has merged a real PR, a second AI tool in the same sprint, and letting each person keep a private rules file. One fence. In git.

A 30-day checklist you can paste

Week 1

• Two or three people, one shipping repo.
• Project rules committed.
• Chat vs Composer split agreed out loud.

Week 2

• PR checklist on every AI diff.
• Rules updated when you find a new “do not.”
• One paired ticket, reviewed together.

Week 3-4

• Add people only if the first group can explain diffs.
• Same repo, same rules, same checklist.
• Write the loop down. Keep it short.

That is cursor ai for developers as a team, not as a seat count.

If the team is stuck

Most teams do not need a new model. They need the fence and the review habit installed on the real repo.

I coach that in Cursor mentoring. I sit with the team on the actual codebase, not a demo. If you need the product built instead of the habit installed, that is the Build path. Most teams do not. They need to stop dumping seats and start reviewing diffs.

Small group. Shared rules. One repo. Then expand.