No-go list for outside engineers before they touch code

Why first-week work goes sideways

Outside engineers rarely cause problems because they are careless. Problems start because they join a codebase full of hidden context, unwritten rules, and old decisions nobody explained.

A new engineer might see a small fix on a pricing screen and treat it like a normal front-end change. On your product, that same screen might connect to billing logic, trial limits, discount rules, or a webhook finance relies on. A minor edit can stop new sales within hours.

The same thing happens in login flows, deployment scripts, admin tools, and data exports. To someone new, these areas look routine. Inside your team, they often sit right next to revenue, customer records, or production stability.

Old habits make it worse. Engineers bring working habits from other teams, and those habits often make sense. They are just wrong for your setup. One team ships small fixes fast. Another wants review on every database change. One team treats staging as optional. Another refuses to deploy without a tested rollback.

People often assume common sense will fill the gaps. It won't. If the boundaries are not written down, new people will make their own calls. Sometimes those calls are fine. Sometimes they create a mess that takes days to clean up.

What the no-go list should include

A no-go list removes guesswork. "Production" is too vague. Name the exact repo, server, dashboard, secret store, setting page, and workflow that can break billing, login, customer data, or deployments.

For most teams, the first version should cover the obvious risk zones: production databases, backups, migration scripts, auth, billing, email, DNS, domain settings, deployment pipelines, build scripts, secrets, cloud permissions, public APIs, webhooks, export jobs, and alert rules that can hide a real problem.

Then define which actions always need approval before work starts. Direct production access is an easy one. Database changes, infrastructure edits, payment flow changes, and any new service that stores customer data should be on the list too.

Keep this part blunt. A contractor should know in 10 seconds whether they can act alone or need a green light.

It also helps to write one simple rule that covers the gray areas: if work touches money, identity, production data, hosting, or customer promises, stop and ask first. That single line prevents a lot of first-week damage.

Name the areas nobody touches without approval

Most early mistakes do not come from bad code. They come from touching the wrong system too soon.

Start with money and access. If a change can charge a customer, lock an account, erase data, or stop logins, nobody should edit it without approval from the person who owns that part of the product.

The usual off-limits areas are familiar:

• billing, payments, and subscription logic
• authentication, user roles, and password reset flows
• production databases, data fixes, and migration scripts
• infrastructure settings such as DNS, backups, secrets, and CI/CD
• pricing pages, legal text, and customer emails

Each one can create expensive problems fast. A billing change can double-charge users. One edit in a password flow can lock out every customer. A rushed database script can wipe good data or leave half the records changed.

Infrastructure deserves the same caution. Outside engineers should not change DNS, deployment settings, backup jobs, or production secrets just because they found the file. On a small team, one bad CI/CD edit can block releases for hours. One bad backup setting can turn a minor bug into a full outage.

Non-code content belongs on the list too. Pricing copy, terms, refund language, and customer emails affect revenue and trust. Even a wording change can create support issues or legal risk if nobody checks it first.

Decide who approves each type of change

Outside engineers slow a team down when nobody knows who can say yes. Give each repo or service one clear owner, and make that person the default approver for changes in that area.

Do not route every decision through the same person. Data access needs its own owner, usually the person who understands customer records, retention rules, exports, and backups. An engineer can write clean code and still create a real problem by querying the wrong table, changing permissions, or exposing private data in logs.

Infra and deployment changes need a separate owner too. Secrets, CI jobs, DNS, containers, scaling rules, and production settings can break a healthy product in minutes. That work should go through the person who runs the environment, not just the person who owns the feature.

A small approval map is enough:

• app code changes go to the repo or service owner
• data reads, writes, exports, and schema edits go to the data owner
• infra, deployment, and secret changes go to the ops owner
• simple copy edits or low-risk UI text changes can go through product or design

That last rule matters. If a contractor only changes a button label or fixes a typo, waiting two days for a senior engineer makes no sense. Give those small edits a fast path, but only if they do not affect logic, tracking, billing, or permissions.

Write a backup rule too. Owners go offline, get sick, or miss messages. Set a response window, then name a second approver. If nobody replies in time, the engineer should stop and wait. Guessing is how a small change turns into an outage.

Set rollback rules before any edit

Outside engineers should not change anything until the undo path is written down. "We can fix it later" is how a small edit becomes a long outage.

A rollback plan should answer one question quickly: what do we do in the first five minutes if this goes wrong?

Start with the reverse step. If someone changes a feature flag, record the old value and where it lives. If they edit a server setting, save the current file first, note the restore command, and attach both to the ticket. Nobody should have to dig through chat to find the last working config.

This matters even more for data. If a change touches customer records, billing, login flow, or production settings, take a backup or snapshot first. For database edits, decide before the work starts whether rolling back code is enough or whether the data needs its own recovery step. If nobody can answer that clearly, the work is not ready.

Most teams do fine with a short set of rules:

• write the undo step before the first edit
• save old config values and file copies in one easy-to-find place
• take a backup or snapshot before risky data changes
• set a hard rollback limit, such as 10 or 15 minutes
• cancel the change if no safe undo path exists

That time limit matters more than people think. Teams often keep poking at a broken deploy because they feel one fix away from solving it. Then 10 minutes becomes an hour. A firm cutoff keeps the damage contained.

This is not red tape. It is cheap insurance. One short note, one saved config, and one snapshot can spare a small team from a week of cleanup.

Build day-one access in the right order

Order matters. If an outside engineer gets access before the rules exist, people fill the gaps with guesswork. Guesswork gets expensive fast.

Start with visibility, not control. Write down what they can see on day one: the ticket board, staging app, logs, docs, and test data. If they do not need a system yet, leave it out. Narrow access makes early work easier to review.

Next, write the no-go areas in plain language. Skip policy wording. Say, "Do not change production billing settings." Say, "Do not run database migrations." Say, "Do not edit live email templates." Clear lines prevent the common first-week mistake where someone assumes a small change is harmless.

Then attach one approver to each risky action. A deploy might need the team lead. A schema change might need the CTO. Access to customer records might need two people to say yes. If nobody knows who approves a change, the answer should stay no.

After that, add rollback steps for the first common tasks. Keep them short enough that someone can use them under stress. For most teams, the basic flow is simple: revert the commit or config change, restore the last working version, check logs and alerts, tell the owner right away, and pause further work until the service is stable.

Finish with a short review before access starts. Ten minutes on a call can save a full day of cleanup.

Give outside engineers safe starter work

Outside engineers should not start with live data, billing flows, or deep backend changes. The first week should teach them how your team names things, ships changes, and spots risk. Pick work that is easy to review and easy to undo.

Documentation is a good start. Ask them to fix setup steps, update old screenshots, or clean up runbooks nobody trusts anymore. You learn how carefully they read, and the team gets something useful even if they never touch production code.

Small UI bugs are another safe option. Choose a low-risk page such as a settings screen, an internal dashboard, or a help page. Skip anything tied to payments, auth, account deletion, or customer records until they have followed your rules a few times without drama.

Old fragile code also gives you a safer path in. Instead of asking for a rewrite, ask for tests around the part everyone avoids. A good contractor can add coverage, describe odd behavior, and show where later changes might break.

Read-only audits work well when you want signal without risk. Let them inspect logs, error reports, and monitoring dashboards, then write a short note about what they see. This often catches noisy alerts, repeated failures, or a bad deploy habit before anyone makes a risky change.

A practical first-week sequence looks like this:

• clean up docs or a runbook
• fix one small UI issue
• add tests around brittle code
• review logs and error groups in read-only mode
• wait on customer data work until the rules hold up in practice

This order is not exciting, and that is the point. Safe starter work shows whether someone asks good questions, respects limits, and leaves the code a little better than they found it.

A simple example from a small product team

A small SaaS team brings in a contractor for two weeks before a pricing update. They need help fast, but they do not give broad freedom on day one. Their no-go list is short and clear: do not touch billing code, payment provider settings, tax rules, or live webhook config without written approval.

So the first task stays small. The contractor works on checkout copy only. They update a headline, tighten the refund note, and fix a confusing field label that has been generating support tickets. The work matters, but it cannot break how money moves.

The team makes the border obvious. Copy lives in one part of the app. Payment logic lives somewhere else. Webhook settings stay behind admin access the contractor does not get. Billing code sits in a protected area, and the team lead says no edits there until the contractor has more context.

A product manager approves the copy change before anything ships. That sounds basic, but it prevents a common mess: engineers guessing at wording that changes legal meaning, pricing intent, or support promises.

The contractor ships during a small release window late in the afternoon, while the product manager and an engineer are both online. The rollback note is already in the ticket: revert commit 8f3c, restore the old checkout strings, and confirm the page text in production. If support sees a spike in confused users, the team can undo the change in minutes.

Nothing dramatic happens. That is the point. The contractor gets useful work done, the team builds trust, and nobody spends the evening fixing a payment outage that started with "a tiny edit."

Mistakes that get expensive fast

Giving a contractor production admin access "just for now" feels convenient for about a day. After that, nobody remembers what they can change, what they already touched, or how to limit the damage if something breaks.

A chat message is another trap. "Looks good" or "please handle it" is not a change approval process. It does not say which system can change, who owns the risk, or who signs off if the result hurts users. When billing, auth, or customer data are involved, vague approval is close to no approval.

Friday edits cause trouble for a simple reason: people disappear for the weekend. If nobody wrote rollback notes before the change, the team has to guess under pressure.

Old docs create quieter damage. Many teams think they have onboarding rules, but the rules sit in a stale folder nobody opens. Outside engineers use the access and instructions they see on day one. If the no-go list is hidden, they will fill the gaps with their own judgment.

Equal access is the last expensive mistake. Contractors do not need the same permissions as long-time staff who know the product history, customer impact, and old incident patterns. Broad access turns a narrow task into company-wide risk.

The cost usually shows up fast:

• a bad deploy that stops signups or payments
• a database edit nobody can fully undo
• a late-night scramble by people who were not part of the change
• security exposure because too many accounts can reach production

A small team can avoid most of this with one page of rules: name forbidden areas, require named approval, limit access to the task, and block any Friday change that has no rollback note.

Quick check before someone starts

A short pre-start check stops most first-week damage. It takes about 10 minutes and saves days of cleanup, awkward calls, and surprise outages.

Ask the engineer to say the limits out loud. If they cannot name the systems they must not touch, they are not ready to start. This matters most for billing, production data, authentication, backups, CI/CD, and customer-facing systems.

Then check the approval chain. They should know exactly who approves code changes, who approves data work, and who approves infrastructure edits. If the answer is "the team" or "someone in Slack," stop there and assign one name for each area.

Use the smallest access level that still lets them do useful work. Read-only access is often enough for day one. They can inspect logs, read code, and learn the system without changing anything by accident.

Before the first edit, ask them to explain the rollback plan in plain English. If they change a config, how do they undo it? If they run a migration, how do they recover? If the answer is vague, the change is not ready.

A simple last check helps:

• they can list the systems and folders they must not touch
• they know who approves code, data, and infra changes
• they have read-only access where write access is not needed
• they can describe how to roll back the first planned change
• one person owns the final go or no-go call

People do better work when the lines are clear. Teams do too. A contractor who starts with safe limits usually moves faster by day three than one who gets broad access on day one.

What to do next

Put the rules on one page and make that page hard to miss. A contractor should see it before they get access, not after their first pull request. If they need to ask where the rules live, the setup is already too loose.

Keep the document plain and specific. It should name the areas nobody touches, who approves each type of change, and what rollback step happens if something goes wrong. Add the people to contact for fast answers.

Most one-page onboarding docs only need five things:

• forbidden systems, files, and environments
• approval names for code, data, infra, and production changes
• rollback steps for each risky change type
• access limits for the first week
• one place to report blockers or unclear rules

After the first contractor week, review what caused friction. Look for repeated questions, slow approvals, and any edit that felt riskier than expected. Then tighten the wording. If a rule caused confusion once, rewrite it before the next person starts.

Small teams often leave this work half-owned. That is where expensive mistakes start. If nobody can clearly say what is off-limits, who signs off, or how to undo a bad change, bring in someone who can own the whole picture. For startups and small teams, that often means a fractional CTO.

Oleg Sotnikov at oleg.is does this kind of work with startups: setting approval paths, defining production boundaries, and putting practical rollout rules in place before outside engineers touch sensitive systems. That kind of oversight is not flashy, but it prevents the sort of first-week mistake that burns two days and shakes trust in the team.