Free checklist

Own the software,
not just the code.

Seven things you should have in your hands when a software project ends, and how to check each one before the last invoice. Download it, add it to your contract, and tick it off as the build goes.

Download the checklistMarkdown file, free, no email needed.

What the checklist covers

  1. The source code, with its history

    The repository with its commits, not a final zip. History is how the next developer learns what changed and why, without you paying for that lesson twice.

  2. Setup instructions someone else has followed

    Written steps that take a developer from a clean machine to a running copy. If nobody outside the original team has followed them, assume they don't work yet.

  3. The accounts, in your name

    Hosting, domain, database, payment processor, error tracking and app store listings, created by you with your builder invited. If they sit in the builder's account, you rent your product rather than own it.

  4. A runbook for how it runs

    What runs where, what talks to what, what happens when it breaks and who to call. One page that answers those is worth more than fifty that describe features.

  5. Tests on the journeys that matter

    Not total coverage: the few paths where a silent failure costs money or a customer, such as signing up, paying and the core thing the product does.

  6. The decision record

    Why this database, why that integration, what was tried and dropped. Without it the next team's first instinct is to rewrite, because undocumented choices look arbitrary.

  7. What happens next, in writing

    Either a support arrangement with an agreed scope and response expectation, or a clean exit with everything above in your hands. Plus one recorded handover session on deploying, monitoring and the likely failures.

Agree it at the start, check it in the middle.

Put this list in the scope before work begins, and halfway through ask someone on your side to follow the setup steps on a clean machine. Whatever is missing is cheap to fix then and expensive at the end.

Read the full guide

Two ways in.
Both reach a person.

Both reach the studio directly.

Or reach us directlyhello@averolt.comLinkedIn
Averolt

Tell us what you’re building.

A new idea or a system that needs to work better. Start with the problem; the details can follow.

You don’t need a finished specification to start.

What’s it about?Optional. Pick any that apply.

Your brief comes straight to us. We read every one and aim to reply within two working days. You can also write to hello@averolt.com.