Key takeaways
- Handover is not a final-day folder; it is a build habit.
- You should receive source code, deployment notes, credentials, architecture notes and admin instructions.
- Bug-fix warranty and maintenance retainer are different things.
- An SLA should define severity, response time and what is excluded.
- Good handover prevents vendor lock-in and makes future developers faster.
A software project is not finished when the demo works. It is finished when your team can run it, recover it, maintain it and hand it to another developer without panic. That is why handover, maintenance and SLA terms should be discussed before the first sprint, not after launch.
Handover checklist
| Asset | What you should receive | Why it matters |
|---|---|---|
| Source code | Git repository with full history | Future developers can audit changes. |
| Deployment notes | How to deploy, rollback and configure environments | Reduces launch and recovery risk. |
| Credentials inventory | Domains, hosting, APIs, payment, email, analytics | Prevents hidden vendor control. |
| Architecture overview | Major services, data model, integrations | Shortens future onboarding. |
| Admin guide | How your team performs common tasks | Reduces support dependence. |
| Known issues | Limitations and backlog items | Makes roadmap honest. |
| Access cleanup | Who keeps access after handover | Protects production systems. |
Bug warranty vs maintenance
- A bug warranty covers defects in agreed deliverables for a defined period. Maintenance covers ongoing updates, security patches, hosting checks, small improvements and support requests. Do not let a vendor blur these into one vague promise.
SLA terms that actually help
- Define severity levels: production down, major workflow blocked, minor bug, enhancement request. Then define response time, target resolution process, communication channel and exclusions. A small SME app rarely needs enterprise theatre, but it does need clear expectations.
The difference between handover and abandonment
Bad vendors treat handover as a zip file. Good vendors treat it as an operating package. Your team should know where the code lives, how to deploy it, which services it depends on, who owns credentials, what is fragile, what still needs improvement and what to do if something breaks.
A simple SLA structure for SME software
| Severity | Example | Expected response |
|---|---|---|
| Critical | Production down, payments broken, login unavailable. | Immediate acknowledgement during support hours and active fix plan. |
| High | Major workflow blocked for staff or customers. | Same business day response with workaround if possible. |
| Medium | Bug affects a subset of users but business continues. | Planned into the next maintenance window or sprint. |
| Low | Cosmetic issue or small improvement. | Backlog item unless covered by retainer. |
You do not need enterprise theatre for every SME app. You do need shared expectations so a Saturday night panic does not become the first time anyone discusses support.
Maintenance models after launch
There are three common support models. The first is ad hoc support, where you pay only when something breaks. It is cheap but slow. The second is a light monthly retainer for updates, small fixes and monitoring. The third is a dedicated developer who keeps improving the product. The right choice depends on how business-critical the software is.
What to prepare before scoping
- How often the software is used.
- What happens financially if it is down for a day.
- Who inside your company can troubleshoot basic issues.
- How often features or policies change.
- Whether customer data, payments or bookings are involved.
Bring these notes into the first conversation and the scope becomes sharper immediately. It also helps me tell you honestly whether you need a one-off build, a dedicated developer, an AI automation, or a smaller fix than you expected.
Frequently asked questions
What should be in a software handover?
Source code, deployment instructions, credentials, architecture notes, admin guide, known issues and access cleanup.
Do I need a maintenance retainer?
If the software runs a real business workflow, usually yes. Even a light retainer can handle fixes, updates and small changes.
Who should own hosting accounts?
The client should own or control hosting, domains and key vendor accounts.
Can Outsourced SG maintain software after launch?
Yes. Some clients keep a developer on a light monthly retainer; others take the code in-house.
Need it built? Explore my services
Want to build with an accountable founder?
I build with handover in mind from day one: source code, docs, credentials and a clean path to maintain the system after launch. You own 100% of the IP, with NDA, handover and no lock-in.
WhatsApp me →