Most agency engagements end with a Slack channel going quiet. You inherit a repo you cannot deploy and a console you cannot read. That is the failure mode we built the handover doc to prevent.
We are a 2-person team. We have shipped 17 production products, 10 of them in our first 7 months. Every Web App build is fixed price, you own the code, and we exit. The handover doc is what makes "we exit" mean something other than abandonment.
Here is what is actually in it.
The architecture map
We start with a diagram of what runs where. Not a marketing diagram. The real one.
It names every AWS service in the build. It shows the request path from browser to database. It marks where state lives and where it does not.
A new engineer should read this and know the system in twenty minutes. If your CTO cannot, the doc failed and we rewrite it.
How to deploy, exactly
The deploy section is a runbook, not a paragraph. It lists the commands in order.
You get the deploy script and the env vars it expects. You get the order infra comes up in. You get what breaks if you skip a step.
This is where ex-AWS Federal experience shows up. We do not hand you a pile of click-ops you cannot reproduce. Infrastructure is in code, so the environment is rebuildable from the repo.
We run the deploy with you once, on a call, on your machine. If it only works on our laptop, it does not work.
Where the money goes
Every AWS account has cost surprises. Most bills hide savings nobody is tracking. The handover doc tells you where your bill comes from before it bites.
It lists the services that drive cost. It flags anything that scales with traffic. It names the knobs you turn if usage spikes.
If a Cloud Bill Audit makes sense later, you will already know your own line items. That is the point. You should not need us to read your own bill.
The accounts and the keys
Ownership is not real until the credentials are yours. So the doc inventories every account and secret.
You get the AWS account, owned by you, root included. You get the domain, the DNS, the certs. You get a list of every third-party service and who controls it.
We tell you what to rotate the day we leave. Then we tell you how. Old vendor keys are a liability, not a convenience.
The parts that are ugly
Every real system has sharp edges. We write ours down instead of hiding them.
The doc has a "known limitations" section. It names the shortcuts we took and why. It names the thing that will break first under load.
A sharp CTO trusts the team that admits the rough edges. We would rather you read about the edge case from us than discover it in production at 2am.
What "done" looks like in practice
This is not theoretical. We ship this way across the board.
A support agent we built and run in production answers customer questions. That system has a handover doc too. The team running it does not call us to restart it.
The same discipline covers a RAG Chatbot build, an OpenClaw Installation, or a Well-Architected Review. Different scope, same exit standard. Fixed price, your code, clean handover, every time.
Why we make exit easy
Lock-in is a business model. It is not ours. We have 18 cloud certifications and 13 AWS certifications between two people, and none of that matters if you cannot run the thing without us.
A clean handover is the honest version of confidence. We think the work stands on its own, so we hand you everything and step back. If you want us back later, you call because the next build is worth it, not because you are stuck.
That is the whole pitch. You get a working app, the account that runs it, and a doc that lets your team take it from here.
Want to see a sample handover doc before you commit? Book a free 30-minute call and we will walk one through with you.