When a build ends

Software handover checklist: what you should receive when a build ends

A clean handover means you can run, change, and hand the software to anyone, without calling the original builder. That requires the code and its full history, documentation, tests, working CI/CD, your own secrets and credentials, and admin access to every piece of infrastructure. If any of that stays with the vendor, you do not own your software, you rent it. Use the checklist below to confirm you actually have everything before you call the build done.

Book a thirty-minute call

Short answer

A clean handover gives you the code, history, docs, tests, CI/CD, secrets, and full infrastructure access, so any competent team can take over without the original builder.

Best for

  • Founders ending an engagement with an agency or freelancer
  • Teams taking a project in-house
  • Buyers who want to avoid vendor lock-in
  • Anyone preparing for due diligence or an audit
  • Products that must outlive their first build team

Not for

  • Throwaway prototypes you never intend to maintain
  • Builds where you have deliberately retained the same vendor for life
  • Internal scripts with no production footprint
  • Work that has not reached a deliverable state yet
// 01

Compare the options

How to tell a clean handover from a lock-in trap.

Dimension Clean handover Vendor lock-in red flags
Code ownership

Repos in your org, with full git history.

Code lives in the vendor’s account, or a zip with no history.

Credentials

All secrets and accounts are yours and rotated.

Keys and logins stay with the vendor.

Infrastructure

You hold admin on hosting, DNS, and observability.

The vendor is the only admin on production.

Documentation

Architecture, setup, and runbooks are written down.

Knowledge lives in the original developer’s head.

Tests and CI/CD

Automated tests and a pipeline you can run yourself.

No tests, or deploys only the vendor can trigger.

Lock-in

Any competent team can take over.

Only the original builder can change anything.

// 02

Where Wavect lands on this

You should be able to fire us and keep your software running. If you cannot, the handover was not clean.

We hand over the code in your own repositories with full history, the documentation and runbooks to operate it, the tests and the pipeline to ship it, and admin access to every account and server it runs on. The secrets are yours and rotated, not ours.

No vendor lock-in is a default, not a premium add-on. The goal of a handover is that any competent team, including your own, can take the work forward without us. That is what owning your software actually means.

// 03

Cost, risk and timeline

Cost Part of the buildA clean handover is included, not an upsell at the end.
Risk Lock-in if skippedA missed item leaves you dependent on the original builder.
Timeline Verified at deliveryRun the checklist before you sign off, not weeks later.
// 04

Where this usually goes wrong

  • Receiving a zip of code with no git history, so you lose the why behind every decision.
  • Discovering production secrets and accounts still belong to the vendor.
  • Finding the vendor is the only admin on hosting, DNS, or the database.
  • Inheriting a codebase with no tests and no runnable pipeline.
  • Relying on knowledge that lives only in the original developer’s head.
  • Calling the build done before anyone verified the handover items.
// 05

The checklist

Confirm every one of these before you accept the handover.

  • Source code in repositories you own, with the full git history intact.
  • Written documentation: architecture overview, local setup, and deployment steps.
  • An automated test suite you can run, with the current results documented.
  • A working CI/CD pipeline you can trigger yourself, not only the vendor.
  • All secrets and credentials transferred to you and rotated off the vendor’s accounts.
  • Admin access to every piece of infrastructure: hosting, DNS, database, and observability.
  • Runbooks for common operations: deploy, roll back, restore, and respond to incidents.
  • Confirmation of no vendor lock-in, so any competent team can take over without the original builder.
// 06

What this looks like in our work

Builds shipped to production and owned by the client.

LivLive

Live
+1,000 Concurrent Users

AR-RWA platform: $2M+ raised through the product, 1,000+ concurrent users, six weeks flat.

Solidity Typescript React
BLOCKCHAIN 2025

PromptID

Live
6 weeks 0 to Production

AI-native assessment platform, 0→production in 6 weeks under compressed market pressure.

NestJS NextJS LangChain
AI 2026
// 07

When this fits, and when it does not

// 01

When Wavect is the right fit

  • You want to own your software outright, not rent it from a vendor.
  • You may take the project in-house or to another team later.
  • You expect documentation, tests, and access as a default.
  • You want a builder who plans the handover from day one.
// 02

When we are not the fit

  • You want a vendor you will never be able to leave.
  • You see documentation and tests as optional extras.
  • You are building a throwaway prototype with no future.
  • You will not take ownership of your own credentials and infrastructure.

If you cannot run your software without the people who built it, you do not own it yet.

// 08

Related services & reading

// 09

FAQs

The code in repositories you own, with the full git history. The history carries the reasoning behind every change, and a zip file without it throws that away. Everything else builds on top of that.
If production secrets and accounts stay with the vendor, they control whether your software keeps running. Credentials should be transferred to you and rotated so nothing depends on the original builder’s logins.
Anything that means only the original builder can change, deploy, or operate the software. Code in their account, undocumented systems, or admin access they will not hand over are all lock-in.
Yes. Without an automated test suite and a pipeline you can run yourself, every future change is risky and slow. They are what let a new team move safely after you take over.
Before you sign off on the build, not weeks later. Run the checklist while the original team is still engaged, so any gap can be closed immediately.
No. No vendor lock-in is a default. The handover items are part of the build, not an upsell at the end.
Last reviewed: byKevin Riedl wiki ↗
Book a thirty-minute call