The handoff model: why we set teams up and leave

Most consulting is built to continue. A project turns into a retainer, the retainer turns into a support line, and two years later the team still calls the consultant before every release. Nobody planned it. The incentives did.

We do it the other way. We set a team up, we hand everything back, and we leave. If the team wants advice later, it asks, and we quote that one piece of work. This piece explains why, and what each step looks like, so you can hold us to it.

We set it up. We hand it back. After handoff you owe us nothing unless you book another session.

The four steps

1. A free 20-minute look. You describe how your team builds, releases or sells with AI today. We say what we would do first. If a setup makes sense, you get one written, fixed price. If not, we say so.
2. A fixed, one-time setup. We build it in your accounts, on your AI plans, with your tools. Sandbox first. Every change is read by two reviewers who did not write it, and your named person presses go.
3. Handoff. Your team gets the keys, the docs and a walkthrough. Nothing runs through us afterwards. We keep no copy, and we confirm that in writing.
4. Optional: advice when you want it. Booked one session at a time, quoted in writing before it starts. No retainer and no minimum. Most teams do not need it.

For the Salesforce audit, the calendar is short and written down in advance. Day 0: payment, a mutual NDA, a short intake form. Days 1 to 3: the first call, and read-only access to your code and one sandbox. Days 7 to 10: the playbook and change list, in writing. Days 10 to 14: the second call, access revoked, and our copy deleted within 7 days and confirmed in writing. The details are on the audit page.

What you own on day one

Ownership is not something we transfer at the end. It never leaves you. Everything is built in your accounts from the first commit, so on day one you already own:

• The repository. Every file, prompt, skill, rule and test lives in your source control, under your organisation. We work in it as guests.
• The memory. What your assistants know lives in your harness, as plain files and a database you can open and export. See one memory, every agent learns.
• The AI plans. They are in your name, paid by you to the vendor, under that vendor’s terms. We never resell AI usage, add a margin or hold your keys.
• The access list. You grant our access, and you can see it and remove it at any time. It is read-only wherever the work allows and sandbox first. For the audit, it never includes production.
• The rules. The review rule, the release gate and the lessons habit are written down in your repository, in words your team can follow without us.

A useful test: if we disappeared tomorrow, would anything stop working? With this model the answer should be no. If it is ever yes, something is running on our side that should not be, and we treat that as a defect.

What handoff actually involves

Handoff is not an email with a zip file. It is a short list, and the engagement is not done until every item is true.

1. Keys. Every credential the setup uses belongs to an account you control. We list them, and you rotate any you want to.
2. Docs. One page per job or skill: what it does, what it may read, what it may propose, and how to turn it off.
3. A walkthrough. We run one real job or one real release with your person at the keyboard and us watching.
4. Your person presses go. The first production go after handoff is yours. If it is not, the handoff is not finished.
5. Access removed. Your admin removes our access. We check that we can no longer sign in, and we say so.
6. Our copy deleted. Every clone, note, export and log we made is deleted, and we confirm it in writing.

What the deletion confirmation says

A promise to delete is worth little if nobody writes down what was deleted. So the confirmation is specific. Here is the template. The parts in angle brackets change; the rest does not.

Subject: Deletion confirmation, <your company>, <engagement name>

On <date>, StratoForce deleted every copy of your material that we held:
  - the read-only copy of your repository
  - notes and working files from our calls
  - exports, screenshots and logs made during the engagement

Access we held, and when it ended:
  - <access, e.g. sandbox user or repository access>: removed by <your admin>
    on <date>. We tried to sign in afterwards and could not.

What we kept: this letter, our invoice, and the signed NDA.

Everything we built is in your accounts, and you own it.

<name>, StratoForce AI, LLC

Two lines in it do most of the work. “What we kept” forces us to name the exceptions, so “we kept nothing” cannot quietly mean “we kept nothing important.” And “we tried to sign in afterwards and could not” turns access removal from an assumption into a check.

How advice works afterwards

AI tools change every few weeks. Sooner or later a vendor will rename a feature, change a default or move a folder, and your team will want a second opinion. That is what advice is for.

• You ask. A question, a change, or a new job you want the setup to do.
• We quote that one thing, in writing. One call or one short piece of work, at a stated price. Nothing starts until you agree.
• Bigger asks get their own setup. If the request is really a new build, it gets its own written, fixed price, like the first one.
• Nothing recurs. No monthly fee, no minimum, no retainer to cancel. Your setup keeps running whether you ever call or not.

The same rules apply during advice as during the setup. Sandbox first. Two reviewers who did not write the change. Your person presses go. Access is granted for the session and removed after it.

What goes wrong when consultants stay

None of this is about bad people. It is about what a standing arrangement does to a team over time.

• The go decision drifts outside the team. If the consultant always reviews the release, the team never learns to. The day the consultant is on holiday, nobody is sure who may say go.
• Access outlives the reason for it. Access granted for a short project is still there a year later, because removing it was nobody’s job. Every standing account is a door someone has to keep watching.
• Knowledge lives in someone else’s notes. The reasons behind a rule, the lesson from the bad release, the fact about a customer’s fiscal year: if they live in the consultant’s files, they leave with the consultant.
• The tooling belongs to the wrong party. If the assistant runs on the consultant’s account, leaving means rebuilding. That is a strong reason never to leave, which is the problem.
• The incentive tilts. A retainer pays the same whether the system needs help or not, and renews more easily when it does. A subscription gives the consultant a reason to keep you dependent. We would rather charge for the work, once.
• Small changes become tickets. A one-line change to a rule waits in an outside queue. The team learns to live with the old rule instead.

Each of these has the same fix: build in the client’s accounts, write the rules down where the team can read them, make the team’s own person press go, remove access at the end, and delete what you held.

What it asks of you

This model asks something of the client too. You need one person who will own the setup after handoff: someone who reads the docs, holds the keys and presses go. It does not have to be a senior hire, and it is rarely a full-time job. But it has to be a named person. If nobody can be named, we say so in the first call, and we would rather not start.

How we charge for all of this is on the pricing page: one-time setup fees, no subscription to us, your own AI plans, and advice when you ask.