Keyword LOGINS

The handover checklist

Ask any vendor what happens when you leave. If the answer involves them exporting something and sending it over, you do not own your operation. You are renting access to it.

Before any work starts

Every account is created under your business email, not ours. If one already exists, we join it. We never create a Systo-owned account and rename it later.
Billing sits on your card, direct to the vendor, at the vendor's own price. We never resell you software or add a margin to it.
You hold the owner role on every platform. Your operator holds admin or the equivalent, never owner.
The vendor list is written down before we touch anything, with what each one is for and what it costs you monthly.
Claude specifically: bring your own subscription, or run on ours alongside yours for $100 a month for as long as we are doing that. Either way the finished work lands on your side.

Why your Claude is worth more on our machines. A model is only as good as what it has been taught to do. Our workstations carry more than 300 skills, and counting, written by the people on this team: procedures for measuring a design system instead of eyeballing it, verifying a render instead of trusting it, recutting a creative as a real re-layout. Your subscription running here inherits all of it on day one. The same subscription on your own machine is exactly as capable as the skills you have curated for it, which for most people is none yet. That gap is most of what you are buying, and it is also why the work costs less than it looks like it should.

While the operation runs

Nothing we build depends on our login being there. If removing an operator's access would take the system down, the system was built wrong, and that is on us to prevent.
Access is retained for the length of the contract. Not because anything is held hostage, but because an operator cannot run an operation they have been locked out of halfway through. Pulling access mid-term stops the work, and we would rather say that plainly than discover it on a Tuesday.
No shared passwords. Individual logins per person, so an access log means something.
Credentials live in your password manager, shared to the operator, not the reverse.
The code lives in a repo created for the build, and you choose how it is held: full owner with us stepping back, or collaborator with us still operating. Either way you can see and export it at any time.
A working copy also lives on our machines. That is how the work actually gets done, and pretending otherwise would be dishonest when we are handling your API keys. It sits behind authentication on systems only your operator can reach, and nobody outside you and the people assigned to your account can see your code or your credentials. Every person on the team is under a signed contract that covers it.
Every automation, agent and workflow sits inside your workspace, not called from ours.
Two-factor codes for the accounts we operate are auto-forwarded to our business address. Our operators run several clients and switch between accounts through the day, so without forwarding, every login means messaging you and waiting. We will give you the exact filter to set up, scoped to the accounts on your vendor list. See the note below, because this one deserves more than a checkbox.

On the two-factor forwarding, since it is the item people stop at. We are asking for it because the alternative is worse for you: an operator who has to message you and wait every time they log in is an operator billing you to sit still. The rule should be a filter scoped to the accounts on your vendor list, not a blanket forward of your whole inbox, and we will write it with you rather than send instructions and hope. If you would rather not, the fallback is a shared password manager with the seat's own entry, which is slower but works. Say so and we will use it.

How your code and credentials are actually held. We are handling your API keys, so vagueness here would be dishonest. Source lives in version control and a working copy lives on the operator's machine, because that is where the work happens. Both sit behind authentication on systems only your assigned operator can reach. Nobody outside you and the people on your account can see your code, your keys or anything else you have given us, and every person on the team is under a signed contract that covers exactly that.

The one honest exception to ownership. Our own internal tooling, the thing operators use to route work between themselves, is not part of what you own. You never log into it and it is not running your operation. Everything that touches your business is on your side of the line, and if you cannot tell which is which, ask. The answer should take one sentence.

Keyword KEEP

The exit checklist

Leaving should be boring. Offboarding is not a data-export project. The operator stops driving, and everything they were driving keeps running, because it was never anywhere else.

The week you tell us

Nothing is switched off. Automations keep running on your accounts, on your billing, with no change.
The playbook is already yours, because it was written in your workspace from the sprint onward, not handed over at the end.
The shared board stays, with every brief, decision and deliverable still in it.
Access ends when the contract does. It is retained for the full term so the operation keeps running to the last day, and it comes off at the end. If you want it gone earlier, that is a conversation, not a switch, because the work stops with it.

What you should verify yourself, rather than take our word for

Log into every vendor account on the list and confirm you are owner.
Change one password and confirm nothing breaks. This is the real test of whether anything was quietly running from our side.
Run the operation once, yourself, with the playbook open. If a step only worked because a person knew something undocumented, that is a gap, and we should close it before we go.
Check the repo is under your ownership if that is the arrangement you chose.
Read the billing and confirm every line is a vendor you recognise.

The term is the commitment, and nothing follows it. Three months minimum, then month to month, and after that you can stop at the end of any month. No exit fee. No data-release fee. No final invoice beyond the month you actually used. Leaving costs you nothing, which is the only arrangement under which staying means anything.

We will ask for exactly one thing on the way out, and it is optional: fifteen minutes on what did not work. That is the only part of leaving we actually care about.

Keywords QA and SIGNOFF

The QA checklist

"The AI checked it" is not QA. A model reports the work is done in the same confident tone whether it is or not. Human QA means a named person re-ran the check the work claims to pass, looked at the thing that fails silently, and wrote down what they verified.

One rule underneath all of it: verify the output, not the report about the output. Every item below is a version of that idea, and every one exists because something shipped, or nearly shipped, without it.

On anything rendered or captured

Count pixels, not bytes. A blank-frame check that measures file size will happily pass an all-black video. The file is the right size, the codec is fine, every frame is empty.
Verify duration after the render, against the source of truth, not against what the render log claimed.
Capture through a sink and assert the frame is not blank. A canvas or WebGL screenshot can return a perfectly valid empty image.
Re-check contrast whenever a background changes near text. A palette change three elements away can quietly push a caption under the threshold.

On anything written

Check every claim against its source, and keep the source. A number with no source is a number we do not publish.
Read it for what it commits us to. Copy that promises a document, a timeline or a capability is a commitment, not a sentence.
Confirm nothing was invented to fill a gap. Where a figure was unavailable, the honest version says so.

On anything built

Open the browser. Tests passing is not the same as the feature working.
Use it on the device it is for. Most layout failures are invisible at desk width.
Check the failure path, not just the happy one.

When a bug survives two fixes

Stop guessing and measure. Two blind fixes in a row means the mental model is wrong, and the third guess will be wrong too. Dump the ground truth instead of theorising about it.

Before it reaches you

A named operator signs it. Not "the team". A person, whose name you have.
What was verified is written down, so you can see what was checked rather than trust that something was.

Keyword SPRINT

The onboarding sprint

Two weeks of no output, on purpose. Everyone who has been burned by an agency was burned by the opposite: work starting on day one, before anybody understood the business.

Days 1 to 2, the operation gets defined

One operation named, in a sentence, with the outcome it owns.
What "done" looks like weekly, written down and agreed.
What is explicitly not in scope, which is the half people skip.
Your named operator introduced, with direct contact and working hours.

Days 3 to 5, accounts and access

Every tool audited: what you already run, what is missing, what is redundant.
Accounts created in your name, billing on your card, per the handover checklist above.
Model stack chosen for this operation specifically, and the reason written down. Claude, Codex, Antigravity or a local model. The choice is per job, not per vendor relationship.
Shared board live, so you can see progress without asking for it.

Days 6 to 8, brand ingest

Voice, tone and vocabulary captured from what you already publish, not invented.
Visual system captured: type, colour, spacing, the things that make output recognisably yours.
The things you never say, which matter more than the things you do.

Days 9 to 10, the playbook

The operation written as a repeatable procedure, in your workspace.
A QA checklist for this operation specifically, derived from the general one above.
Escalation path: what the operator decides alone, and what comes to you.
A dry run, end to end, producing one real piece of work you review.

What you should have at the end of day 10. Not a report. A working operation, a named person accountable for it, a written playbook in your own workspace, and one finished piece of work to judge it by. If those four things are not there, the sprint has not finished, and week three does not start until it has.

Four checklists.