Hiring someone to set up Claude Code for a non-developer team

The short answer

“Set up Claude Code for my team” sounds like an installation. It is not. Installing the tool takes minutes. What you are paying for is everything that makes five different people get the same, safe behaviour from it without re-explaining your business in every session.

That comes down to five things in your shared project and one decision outside it:

1. Shared instructions: what the tool must know about how your team works.
2. Skills: your repeated procedures, written once so anyone can trigger them.
3. Permissions: what the tool may do without asking, and what it may never do.
4. Scheduled jobs, if any: work that runs with nobody watching.
5. A hand-over: a short guide your team can follow, and a named owner for each file.
6. The decision: whose plan and usage limit all of this runs on.

Ask for those six by name. A seller who quotes “setup and training” without them is quoting the easy part.

I build and run my own unattended jobs with Claude Code, and the points below are what that work has shown me. I have not set it up for a team or shared a setup with other people, so where this guide talks about five users, it is applying what one heavy user learned, not reporting a team rollout. The guide to what a Claude Code expert does covers the single-project case; this one is about a team.

Shared or personal: what goes where

Claude Code reads a project instructions file called CLAUDE.md at the start of every session. According to the documentation, a project’s file is meant to be shared with the team through source control, and each person can keep a separate CLAUDE.local.md for personal preferences that is not committed. The same split exists for settings: a shared .claude/settings.json for the team, and a personal .claude/settings.local.json for exceptions.

For a non-developer team, the practical rule is simple:

Belongs in the shared files	Belongs in personal files
Folder layout and file naming rules	Your own shortcuts and preferred tone
What “done” means for your common tasks	Test data and sandbox links only you use
What must never be changed or sent outside	Personal reminders
Team procedures (as skills)	One-off experiments
Permission rules for everyone	Your own extra approvals

My own workspace has one project instructions file of this kind. It holds the folder layout, the file naming rules and a handful of rules that should never be relearned, and the tool reads it every session. Writing that file is most of the value of a setup. Ask to see a draft of yours before the work is accepted, and read it: if a rule surprises you, it will surprise the tool’s behaviour too.

Sharing these files needs a shared place to keep them, usually a git repository. If your team has never used one, include that in the scope; the basics of git and version history explain why it also gives you an undo button for every change the tool makes.

Skills: your procedures, written once

A skill is a folder with a short instruction file describing one procedure: “write the weekly client update”, “turn a meeting transcript into notes”, “check a contract against our checklist”. The documentation describes two ways they start: the tool picks one up on its own when a request matches its description, or a person calls it by name. Project skills live in .claude/skills/, and committing that folder gives the whole team the same set.

My workspace triggers its skills from keywords in a normal request, so nobody has to remember a command. That is convenient, and it means the description of each skill matters as much as its content.

Two things make skills work for a team:

• One owner per skill. Procedures change. A skill nobody owns keeps teaching the old way.
• One home per rule. In my content pipeline, the same decision once lived in two files. I updated one; the other kept the old rule, and seven items were queued to go out half-finished while the log called it normal. If a rule is in the shared instructions, the skill should point to it, not copy it.

Permissions: instructions advise, settings enforce

This is the point most team setups miss. The documentation is direct about it: Claude Code treats CLAUDE.md as context, not enforced configuration. “Never delete client files” in the instructions is a request. A deny rule in the shared settings is a wall.

So ask for both:

• Instructions that explain the why (“client folders are read-only because they are synced to the client”).
• Settings that enforce the what (deny rules for those folders, and for commands nobody on the team should run).

The documentation also notes that shared allow rules only apply once each teammate has trusted the project folder, while deny rules apply straight away. Your setup person should walk each person through that first opening.

Unattended jobs need the tightest limits. My nightly content job may edit files and search the web, and may not run shell commands at all. If it misreads its instructions, the damage stops at what it was allowed to touch.

Scheduled jobs: the part that fails quietly

If the setup includes anything that runs on a timer, treat it as an automation project, not a Claude Code feature. My own nightly job taught me four things I would now put in any brief:

Then test it the way it will really run. A job that receives its instructions through the command line can lose most of them, and a machine asleep at the scheduled time skips the run. Neither shows up when someone presses Run by hand. The acceptance checklist for unattended automations lists the conditions to force before you pay.

One more lesson from my own notes: what is written down and what is set are not always the same. I once recorded a scheduler change as done; a check a week later showed it had never applied. It was the kind of change that needs admin rights. Ask the person who set it up to show the live settings, not the notes.

The decision: whose plan, whose limit

Every session and every scheduled job uses up the usage of some account. For a team, that question has three parts: which plan each person uses, which account the scheduled jobs run on, and what happens when a limit is reached.

It is not theoretical. In September 2026 my nightly content job hit a monthly spending limit at 01:19: it produced part of its output, then ended with an error. I kept a second job switched off, because it would have drawn on the same limit. Make sure the setup names who watches usage, and what stops first when it runs out. The guide to running costs after hand-over has a sheet for the monthly side.

What to ask for: a deliverables table

Deliverable	What good looks like
Shared instructions file	Plain language, short, read and approved by you
Personal file template	Each person knows what goes there and that it is not shared
Skills	One per repeated procedure, each with a named owner
Shared settings	Deny rules for what must never happen, allow rules for routine work
Scheduled jobs (if any)	Pause switch, once-per-day guard, fixed-rule check, alert
Usage plan	Which accounts, which limits, who watches them
Team guide	One page: how to start, how to ask, what not to do, who to call

Starting packages for Claude Code and AI coding work are listed on the AI-built app page. What moves the price here is the number of skills, whether scheduled jobs are included, and how much of your process has to be written down for the first time. Use the page’s brief and add one line: “Set up for a team of N people who do not write code.”

Eight questions to send before you order

1. What will you put in the shared instructions file, and will I approve it before hand-over?
2. Which of our procedures will become skills, and who will own each one?
3. Which actions will be blocked by settings, not only discouraged by instructions?
4. How will each person’s first session be set up, including trusting the project folder?
5. Will anything run on a schedule? If so, how do I pause it, and how will I know it failed?
6. Whose account and plan does each person and each job use, and what happens at the limit?
7. Where will these files live, and how do we undo a bad change?
8. Who updates the files when our process changes, and is that included or a new order?

Where it goes wrong anyway

• The instructions grow until nobody reads them. Ask for a short file and a habit of removing rules that no longer apply.
• People work around the setup. If the shared skills are slower than typing a request from scratch, nobody uses them. Ask for a session with your real tasks.
• The process changes and the files do not. That is maintenance. Agree it in the contract before the first order.

Wrap-up

A good Claude Code setup for a team is mostly writing: what the tool must know, which procedures repeat, what it may never do, and who looks after each piece. Ask for the shared files by name, insist that the important limits live in settings and not only in instructions, test any scheduled job the way it will really run, and decide whose limit it all spends before the first month’s bill does it for you.