The Software Handover Test: 37 Things a Zimbabwean Business Should Own Before Its Developer Leaves

A Harare tour operator builds its entire booking enquiry workflow around a WhatsApp Business account. The developer who set it up registers the account using their own phone number during development, intending to transfer it later. The developer completes the project and moves on. Two years pass. The number is eventually reassigned by the network operator. Meta's verification system locks the account. The business's primary customer contact channel stops working, and the recovery process requires demonstrating original access to a phone number the business never owned.

This is not a story about a dishonest developer. The registration was done quickly at the start of the project because the developer's phone was in the room. The word "later" was said and meant. The engagement ended and later never arrived.

Across every sector in Zimbabwe, some version of this story is common. The domain expires because the registrar bill went to a Gmail address the developer has since abandoned. The hosting account cannot be renewed because it was set up with the developer's banking card. The GitHub repository disappears because it lived in a personal account that has since been closed. The business has paid for a system it cannot operate, cannot extend, and cannot hand to a new developer without tracking down someone who may no longer be reachable.

Paying for software development does not automatically transfer ownership of the system. The code is one layer. The domain, hosting, databases, credentials, payment integrations, third-party accounts, and operational documentation are the rest of it. This article is a 37-item checklist covering every layer. It can be used before a new engagement begins, as an audit of a system already running, or as the formal handover requirement in any development contract.

What Zimbabwean Businesses Are Actually Paying For When They Commission Software

When a business commissions a software system, it pays for four layers, though most businesses only discuss one.

Layer 1 is the code. Layer 2 is infrastructure: domain, hosting, servers, databases, and network configuration. Layer 3 is credentials: accounts, API keys, passwords, and payment integrations. Layer 4 is knowledge: documentation, runbooks, and the institutional understanding that allows anyone other than the original developer to maintain the system.

A business that secures Layer 1 but not Layers 2, 3, and 4 has purchased something it cannot run independently.

Why Zimbabwean Software Handovers Fail More Often Than They Should

The cause is almost never malicious intent. It is speed. A developer registers the domain in their personal account because the business did not yet have a registrar login. They set up the WhatsApp Business account on their phone because verifying a business number requires a device physically present. They create the AWS account under their own email because it was the path of least resistance at the end of a long launch day.

In development engagements where no formal contract defines handover requirements, which is the common pattern in Zimbabwe's software market, there is no offboarding checklist, no credential transfer schedule, and no final payment tied to demonstrating independent access. The developer finishes the visible work, the relationship drifts to a close, and the handover that was supposed to happen later is the first casualty. As the WordPress Era article documents, most local software projects run on personal goodwill rather than professional structure. Handover fails for the same reason many projects fail: the process was never specified.

What Vendor Lock-In Looks Like When There Is No Vendor

Vendor lock-in usually describes a technology company that traps customers in its platform. In Zimbabwe's software context, lock-in more often originates from individual developer credential ownership, with no contract, no exit clause, and often no awareness that a problem exists until something breaks.

In practice: the business cannot access its own database because the credentials exist only in an environment variable file on the developer's machine. Verizon's research places the average cost of even small data loss events (fewer than 100 files) at $18,000 to $35,000; ITIC's 2024 Hourly Cost of Downtime Survey found that over 90% of mid-size businesses report a single hour of system unavailability costing more than $300,000. In each case, the root cause is identical: the business cannot reach what it needs because the path to it was never transferred. It cannot renew its domain because the registrar will not communicate with anyone other than the registered email address. It cannot update the payment webhook URL because the EcoCash merchant account is tied to the developer's identity. None of these problems appear on the day the system launches. They appear when something breaks, when the developer is unreachable, or when the business needs to move the system to a different provider.

The 37-Point Handover Checklist

The checklist is organised across eight categories. For each item, the question to ask is: if the developer were unreachable from tomorrow, could the business handle this independently?

Domain and Identity

1. The domain registrar account is accessible using a business email address and a business-controlled password. If the domain is registered at GoDaddy, Namecheap, Afrihost, or any other registrar and only the developer can log into that account, the business does not control its own address on the internet.

2. The domain registrant contact details list the business or a named business owner, not the developer. Many registrars distinguish between the account holder and the domain registrant: both must belong to the business.

3. Domain auto-renewal is enabled and the payment method on file is the business's own card or banking detail. An expired payment method at the registrar is a common and preventable cause of unintentional domain lapse.

4. The DNS management interface, which may be hosted separately from the registrar (Cloudflare is a common choice), is accessible to a business account. DNS settings control where web traffic, email, and other services point, and a business that cannot access them requires the original developer's involvement for any future technical change.

5. All current DNS records are documented in writing: A records, CNAME records, MX records for email routing, and any TXT verification records added for Google, WhatsApp, payment services, or email senders. This document means a future technical team can rebuild the configuration without needing to interrogate the live system.

6. The SSL certificate is documented: the issuing authority, the expiry date, and the renewal process. Certificates that expire unnoticed take websites offline overnight and suppress search rankings until they are renewed.

Hosting and Infrastructure

7. The web hosting provider account is accessible to the business. If the site runs on shared hosting, the business can log into the control panel independently. If it runs on a VPS or dedicated server, the business holds the server's IP address, SSH key, and root or sudo credentials.

8. Cloud provider accounts, including AWS, Google Cloud Platform, Azure, DigitalOcean, and Vultr, are registered to a business email address, not the developer's personal Gmail or Microsoft account. This is a significant and recurring single point of failure in professional software deployments.

9. All server access credentials are documented and held by the business: IP addresses, SSH keys, usernames, and passwords, stored in a location the business controls rather than on the developer's local machine.

10. All environment variables for the production server are documented. Environment variables include database connection strings, API keys, and configuration settings the application needs to function. Without them, having the code alone does not mean the system can be restarted.

11. File or object storage accounts, including Amazon S3, Cloudflare R2, or equivalent, are accessible to the business account. Uploaded files, user documents, and images are often stored separately from the code and are lost if only the developer controls the storage bucket.

12. A monitoring or uptime alert is configured to notify a business email address when the system goes down. If downtime notifications go only to the developer's inbox, the business learns about outages from customers rather than from its own infrastructure.

Source Code and Deployment

13. The source code repository (GitHub, GitLab, Bitbucket) is owned by a business organisation or account, not the developer's personal account. If the developer's personal account is closed or made private, everything stored in it disappears with it.

14. The full commit history is included, not only a snapshot of the current codebase. Commit history documents every change to the system and is the primary tool for diagnosing future bugs or understanding why architectural decisions were made.

15. All active branches are present and accounted for: development, staging, and production branches, not only the main branch.

16. The process for deploying a new version to the live system is documented step by step, in enough detail that a person who has never worked on the project before can execute it without calling the original developer.

17. Automated deployment pipelines, such as GitHub Actions, CircleCI, or Vercel, are configured under a business account and documented, including what they trigger, where they deploy, and what credentials they depend on.

18. The staging environment, if one exists, is accessible to the business and documented separately from production. A business that can only access the live system has no safe environment in which to test changes before they affect customers.

Database and Data

19. Full database credentials are documented and transferred: host address, port number, database name, username, and password. These are distinct from the application's user-facing login and must be verified independently of it.

20. A complete recent database backup exists and is stored in a location the business controls, not on the developer's machine or in the developer's personal cloud storage account.

21. The database schema is documented or exported as a file: every table, its relationships, and its field types. Schema documentation allows a future developer to understand the data model without reverse-engineering the live database.

22. The backup schedule is documented: how often backups run, where they are stored, and how long they are retained before deletion.

23. Data restoration has been tested at least once on a copy of the backup. A backup whose restoration has never been tested is a backup whose integrity has never been confirmed.

Payment Infrastructure

24. The Paynow merchant account is registered to the business, with a business email address and a verified bank account or EcoCash number the business controls. If merchant registration details belong to the developer, settlement routing becomes unpredictable and corrections require Paynow's compliance team.

25. EcoCash merchant or integrator credentials are documented and held by the business. If the integration was configured through the developer's credentials, payment routing may stop functioning correctly when those credentials expire or are deactivated.

26. Any other payment rail credentials, including ZimSwitch, Mastercard or Visa gateway access, or Stripe for USD transactions, are documented and held by the business.

27. Payment webhook configuration is documented: the URL the payment provider calls when a transaction completes, and the secret used to verify that call. If either changes without updating the payment provider, payments appear to process but the application never receives confirmation.

Third-Party Services and Accounts

28. The WhatsApp Business account is registered to a phone number the business owns and controls. An account tied to a developer's number can be lost permanently if deactivated or reassigned, and Meta recovery requires demonstrating original access to the number.

29. Google Analytics and Google Search Console are linked to a business Google account at owner-level permission. View access granted through a developer's account cannot be transferred and disappears when that account closes.

30. The email delivery service used to send transactional emails, whether SendGrid, Mailgun, AWS SES, or similar, is registered to the business and its API keys are documented. Without this, the system cannot send password reset emails, booking confirmations, or any other automated customer communication.

31. Any SMS gateway account used for OTP verification or customer notifications is registered to the business with credentials documented.

32. All third-party services the application depends on are listed: what each does, its cost, billing date, and the credentials or API keys it uses. This list maps everything that breaks if a subscription lapses or a credential rotates without the application being updated.

Access Control and Security

33. The developer's direct access to production systems is scoped appropriately or revoked at the conclusion of the engagement. This is standard operational security practice, not a statement of distrust, and any professional developer should expect and facilitate it.

34. At least one business staff member holds full administrator access to every critical system in the stack: hosting, cloud accounts, domain registrar, repository, and payment accounts.

35. Two-factor authentication recovery codes for critical accounts are stored in a secure location the business controls, not only on the developer's device. Losing access to a 2FA recovery code can make an account permanently inaccessible regardless of whether the correct password is known.

36. The process for revoking and rotating credentials when any team member leaves is documented in advance. Planned credential rotation takes roughly ten minutes per system. Unplanned rotation requires simultaneous access to every system at once and takes hours.

Operational Documentation

Most handover requirements stop at credentials. The operational documentation layer is what separates a system the business can maintain from one it can only observe. This final item is the least glamorous and the most frequently missing.

37. A runbook exists in writing: what to do when the system goes down, who to contact in what order, how to restart each service, how to escalate if restart fails, and what the known failure modes are. The runbook does not need to be comprehensive. It needs to be accurate enough that a person who has never worked on the project can keep the system running, or give a new developer enough context to start without beginning from scratch.

How to Use This Checklist Before, During, and After a Developer Engagement

This checklist applies in three situations. Before a new engagement: give it to the developer and make final payment conditional on demonstrating independent access to every item. As an audit of an existing system: run it while the developer relationship is still active, which makes resolution a brief exercise rather than a recovery project. As an ongoing standard: verify the relevant items every time a new integration is built or a subscription is set up.

The businesses that score poorly on this checklist are not the ones that used incompetent developers. They are the ones that never asked for a handover at all. The checklist protects against the specific, preventable category of loss where a business cannot access its own system because nobody asked who owns the credentials.

Most of these problems resolve in an afternoon when the developer relationship is still active. When it is not, the same problems take weeks and sometimes require legal correspondence. The difference is whether someone asked the right questions before the engagement ended.

Sources

1. Verizon. (2024). Data Breach Investigations Report. Verizon Business. (Small data loss events cost $18,000-$35,000 on average; large incidents up to $15.6 million.)
2. ITIC. (2024). Hourly Cost of Downtime Survey. Information Technology Intelligence Consulting. (Over 90% of mid-size businesses: one hour of unavailability costs more than $300,000.)
3. Capterra / Gartner Digital Markets. (2025, October). 2026 Software Buying Trends Report. Business Wire.
4. Meta Business Help Center. (2026). WhatsApp Business account verification, number migration, and recovery requirements.
5. POTRAZ. (2024). Postal and Telecommunications Regulatory Authority of Zimbabwe: Licensed Operators Register. Government of Zimbabwe.
6. Paynow Zimbabwe. (2026). Paynow Merchant Integration Documentation.
7. Sparkline Labs. (2026). The WordPress Era Never Ended. It Just Learned to Prompt.
8. Sparkline Labs. (2026). Will AI Make Software Cheaper in Zimbabwe? Why the Code Cost Was Never the Problem.