Handover and documentation

A project isn't finished when the work is built — it's finished when you can operate, maintain, and build on it without us in the room. Handover is a deliberate step, not an afterthought.

What you receive

The exact handover depends on the project, but typically includes:

• Documentation of what was built — architecture, configuration, and the decisions behind them.
• Runbooks for routine operations and common issues ("how to add a user," "what to do if X alerts").
• Credentials and access, transferred securely, with you as the owner of your own systems and accounts.
• As-built records for infrastructure — network diagrams, rack layouts, IP schemes, cabling labels.
• Source code and assets for software, in your repositories.

Documentation built as we go

We don't write documentation in a panic at the end. It's produced alongside the work, so it reflects what was actually built rather than what was planned months earlier. That's also why it's accurate enough to be useful.

Training and knowledge transfer

For systems your team will operate day to day, we include a walkthrough — live or recorded — so the people responsible understand how things fit together and where to look when something needs attention. The goal is genuine independence, not documentation that sits unread.

Ownership is yours

You own your systems, your data, your accounts, and your code. We're a partner, not a hostage-taker — there's no lock-in designed to make leaving painful. If you later bring work in-house or move elsewhere, the handover materials are built to make that possible.

After handover

Many clients keep us on for ongoing support, monitoring, or further work — but that's a choice, not a dependency. How ongoing support works is covered in Support and AMC.