Why Zimbabwean Businesses Keep Rebuilding the Same Software

A Harare distribution company is on its third stock management system. The first was a spreadsheet that became unmanageable at around 200 SKUs. The second was built by a developer who was available, reasonably priced, and reliable until, eighteen months in, he was not. The third was commissioned because the new developer who inherited the second system said the codebase was too difficult to maintain and it would be faster to rebuild from scratch.

The business agreed. The third system launched eight months ago. The developer who built it has recently become difficult to reach.

Nobody in the company can explain why the second system stored prices the way it did. The staff member who understood that logic left a year ago. The database from the second system is backed up in a format the third system cannot read. Three reports that management relied on have not been recreated, because the new developer does not know what they were calculating.

This is not a story about bad developers or an unlucky business. It is the software rebuild cycle, and it repeats not because each successive developer is worse than the last, but because each successive system is handed over with the same missing documentation, the same undescribed business rules, and the same unowned architecture. What changes between each rebuild is the technology. What does not change is what the business never built into its relationship with the system.

The root cause is not cheap development. It is the systematic absence of anything that would allow a system to be understood, maintained, or transferred by anyone other than its original creator.

How the Rebuild Cycle Progresses in Zimbabwean Businesses

The cycle has recognisable stages. Not every business passes through all of them, but the sequence is consistent enough that each stage predicts the next.

Why the Spreadsheet Phase Ends in a Developer Engagement

Every rebuild cycle begins with a spreadsheet that worked. It tracked inventory, client records, job schedules, or delivery manifests. It worked until the data grew beyond what one person could manage in a single file, until two people needed to update it simultaneously and a version control problem destroyed an afternoon's work, or until the reports it generated began requiring more manual assembly than the underlying data justified.

The spreadsheet is not the problem. The problem is that the business, having decided the spreadsheet cannot continue, goes to market with a requirement described in terms of what the spreadsheet did rather than what the operation needs. "We need a system to do what this spreadsheet does, but properly."

This brief does not contain the business rules. It does not contain the edge cases. It does not contain the exceptions that three years of spreadsheet management have accumulated as informal workarounds. It describes the visible surface of the operation, not its logic.

Why the First Developer Always Creates a System That Cannot Be Handed Over

The first developer builds to the brief. The brief describes surface behaviour. The business rules that govern edge cases, the exceptions that apply to specific customers, the calculation logic that the original spreadsheet author understood intuitively but never wrote down: these are discovered during development through conversation, not through documentation.

The conversations are not written down. The decisions made in those conversations, including the ones that shape the data model and the business logic, exist in two places after the engagement concludes: in the code, and in the developer's memory. The code is opaque without context. The memory leaves with the developer.

When the developer becomes unavailable, the business has a running system it cannot change, a database it cannot explain, and a set of business rules encoded in logic that no one currently employed can articulate. This is not a failure of the developer's technical skill. It is the predictable outcome of an engagement that was never structured to produce anything transferable.

Why the Second Developer Always Chooses to Rebuild

A developer inheriting a system with no documentation faces a choice: understand what exists or replace it. Understanding what exists requires reading code whose logic cannot be verified without the context in which it was written, reverse-engineering a database schema to infer the business rules it encodes, and validating that understanding against staff who may themselves be uncertain about why things work the way they do.

Rebuilding is faster. It starts from a clean state. It produces code the new developer understands because they wrote it.

This is not cynical reasoning. Given the information available, it is often the rational choice. The problem is not that the developer chooses to rebuild. The problem is that the rebuild produces the same undocumented system as the one it replaced, which means the next developer will face the same choice in eighteen months.

Why "Cheap Development" Is Not the Root Cause

The rebuild cycle is routinely attributed to cheap development: the business paid too little, got too little, and is paying the price. This explanation is both partially true and fundamentally misleading.

It is partially true because low-cost development engagements typically have narrower scope, shorter timelines, and less margin for the work that does not produce visible features: documentation, comments, handover preparation, and architectural explanation. A developer paid to produce a working system by a given date will produce a working system by a given date. They will not voluntarily produce documentation that was not in scope and for which they are not being paid.

It is fundamentally misleading because paying more does not solve the documentation problem. Expensive engagements in Zimbabwe produce undocumented systems at similar rates to inexpensive ones, with the additional disadvantage that the undocumented system is more sophisticated and therefore harder to inherit. The variable that determines transferability is not the development budget. It is whether documentation was specified as a requirement.

A system with no specification for what it must leave behind will leave nothing behind. This is not a market failure or a developer failure. It is an organisational failure to understand that software is an asset requiring ongoing stewardship, not a service that ends when the invoice is paid.

As the custom software types article in this series identifies, there are seven fundamentally different things Zimbabwean businesses call "custom software," each with different architecture and different ongoing requirements. None of the seven types is self-documenting. All seven require explicit documentation to survive a vendor change. The amount spent on development does not change that.

The Three Artefacts That Would Let a System Survive a Vendor Change

A system can survive a vendor change if, and only if, the incoming developer can understand what the system does and why it was built the way it was without needing to ask the outgoing developer. Three documents make this possible. All three are routinely absent from software implementations in Zimbabwe.

A Data Model Document That Explains What Every Field Means

The database schema tells a new developer what tables exist and what columns they contain. It does not tell them what those columns represent in the business. A column called status with values 1, 2, and 3 is opaque without a document that says: 1 means the delivery is scheduled, 2 means it has left the depot, 3 means it has been confirmed by the receiving party, and 4, which appears in old records but was deprecated in version two, means it was cancelled before dispatch.

A data model document closes this gap. It maps every table to the business concept it represents, every significant column to the rule it encodes, and every relationship to the business logic that determines it. It is not a technical document: it is a translation between the database structure and the operation it models. A new developer who has read it can work with the code. One who has not must infer meaning from structure and accept the risk of inferring incorrectly.

A Business Rules Record That Captures Why the System Works the Way It Does

Business rules are the decisions that determine how the system behaves in non-obvious situations. Which customers receive a different pricing tier and why. What happens to an order that has been partially delivered when a route driver reports a problem. How the system handles a payment that arrives in ZWG on a USD-priced invoice. When a booking can be cancelled without a fee and when it cannot.

These rules exist in every system. In well-documented systems they are written down. In most Zimbabwean software implementations they exist only in two places: the code that encodes them, and the memory of the staff who know the exceptions from experience. When a developer leaves, the code survives but the intent behind it does not. When staff turn over, the memory of the exceptions erodes. A system in its third year, with significant staff turnover since launch, is often operating with business rules that no one currently in the organisation can fully articulate.

An Architecture Decision Log That Records What Was Built and What Was Rejected

Every software system embeds decisions whose rationale is invisible from the outside. Why does this system use a flat table structure for inventory rather than a hierarchical one? Why does it store prices inclusive of tax rather than exclusive? Why does the WhatsApp integration batch notifications rather than send them immediately? These decisions were made because alternatives were considered and rejected, usually for good reasons. Without a record of what those reasons were, the next developer may reverse the decision, discover the original problem, and spend a week diagnosing an issue that the first developer solved in day three of the project.

Architecture decision logs are not formal documents. They are brief records: what decision was made, what alternatives were considered, and why this option was chosen. A system with these records can be inherited by a developer who understands not just what exists but why. A system without them presents every structural decision as an unexplained given.

How Institutional Knowledge Fragments When a Developer Leaves

A software system carries three distinct categories of institutional knowledge, each held and lost differently when a vendor relationship ends.

Technical knowledge covers how the system is built: the architecture, the codebase, the deployment configuration, the integration points. This knowledge lives almost entirely with the developer. It is not written anywhere in a form accessible to the business. When the developer leaves, technical knowledge leaves with them. A new developer inheriting the system starts from a reconstruction, not a transfer.

Business rule knowledge covers why the system works the way it does: the edge cases, the exceptions, the calculation logic. This knowledge is held jointly between the developer who implemented it and the staff who use it. Neither holds the complete picture: the developer knows what was implemented but not all of the business context behind it, and the staff know the business context but not how it was implemented.

When either party leaves, the overlap shrinks. When both have turned over, the rules that governed the system's behaviour become partially irrecoverable.

Operational knowledge covers how to run the system: what breaks under what conditions, what the workarounds are, what the known limitations are, and how to recover from incidents. This knowledge accumulates through experience and lives in the memory of whoever has been administering the system longest. It is the last category to be documented and the first to disappear.

The rebuild cycle perpetuates because each rebuild discards all three categories and starts accumulating them again from scratch. The business does not become more capable with each cycle. It becomes more experienced at starting over.

The Test for Whether a Business Owns Its System or Is Renting It

The distinction between owning a software system and renting it is not about the contract. It is about what the business can do independently of the developer.

A business that owns its system can answer the following without contacting the developer: what does the database table invoices contain and what does every column in it mean? What happens when a customer's account balance goes negative? What third-party services does the system call and what would break if each one were unavailable? How is the system deployed and who can do it?

A business that cannot answer these questions does not own its system. It operates a system that belongs, in practical terms, to whoever currently holds the technical knowledge. The software handover checklist documents the 37 categories of access and documentation that constitute genuine ownership. A business that cannot complete that checklist independently is one developer departure away from another rebuild.

This is not a failing of the developer. It is the consequence of an organisational posture that treats software as a service rendered rather than an asset managed. Changing that posture requires specifying documentation as a deliverable with the same clarity as features, making ongoing knowledge transfer a condition of ongoing engagement, and building internal administrative capacity that does not depend entirely on the developer's availability.

What Breaking the Rebuild Cycle Requires

Breaking the cycle requires treating documentation as infrastructure rather than overhead. Infrastructure is built before it is needed. Overhead is cut when budgets are tight. Documentation that exists only when there is budget for it will not exist when a developer departs unexpectedly, which is the moment it is needed most.

Three practical requirements follow. First, documentation must be scoped as a deliverable in the initial engagement, not as a vague obligation but as a specified set of artefacts: a data model document, a business rules record, and an architecture log, each with defined content requirements.

Second, the incoming developer at each handover must demonstrate understanding of the system before the outgoing developer's access is reduced. Handing over credentials is not a handover. Demonstrating that the incoming developer can explain what the system does, and why, is.

Third, the business must designate someone internally who is responsible for the system's documentation, not the developer. This person does not need to be technical. They need to be able to read the documents, ask the developer to update them when something changes, and preserve them through vendor transitions. The total cost of ownership model for Zimbabwean software makes clear that post-launch operational costs consistently exceed development costs. Documentation is among the lowest-cost items in that model and the highest-leverage: it determines whether any competent developer can maintain the system or only its original creator can.

The rebuild cycle is not an industry problem or a developer problem. It is a measure of whether an organisation understands what it actually owns when it commissions software. A business that has gone through two rebuilds without changing what it requires from a development engagement will go through a third. The pattern does not break until the requirement changes: not "build us a system" but "build us a system that we can own, explain, and hand to anyone."

Sources

1. Ensmenger, N. (2010). The Computer Boys Take Over: Computers, Programmers, and the Politics of Technical Expertise. MIT Press. (Maintenance has accounted for 50 to 70 percent of total software expenditure since the early 1960s.)
2. Nygard, M.T. (2018). Architecture Decision Records. IEEE Software, 35(6).
3. Stripe, Inc. (2018). The Developer Coefficient: Software Engineering Efficiency and the $300 Billion Opportunity.
4. Sparkline Labs. (2026). The Software Handover Test: 37 Things a Zimbabwean Business Should Own Before Its Developer Leaves.
5. Sparkline Labs. (2026). The Hidden Cost of Software Nobody Budgets For.
6. Sparkline Labs. (2026). What Does "Custom Software" Actually Mean? Seven Completely Different Things Zimbabwean Businesses Call Custom Software.
7. Sparkline Labs. (2026). Build, Buy, Integrate or Change the Process? The Zimbabwean Technology Decision Framework.