1. Introduction
Ghana's software development industry is growing. More businesses are commissioning custom software. More developers are entering the market. More organisations are building internal technical teams. This growth is welcome — but it is accompanied by a pattern we observe consistently in our consultancy work: software that is delivered, works initially, and then becomes increasingly difficult to maintain until it is eventually abandoned and rebuilt from scratch.
This paper argues that the root cause of this pattern is not talent — Ghana has capable developers. It is the absence of formal development practices: version control, automated testing, documented deployment processes, and code review. These practices are not optional extras for advanced teams. They are the minimum conditions for software that survives beyond its first year in production.
2. What We Observe in Practice
2.1 Version Control Is Not Universal
In our work with Ghanaian software teams and when inheriting codebases from other developers, we frequently encounter projects with no version control history. Changes are made directly on the production server. There is no record of what was changed, when, or why. When something breaks, there is no way to identify when the breaking change was introduced or revert to a known good state.
This is not a criticism of individual developers — it reflects an environment where formal practices are not taught, not expected by clients, and not enforced by any industry body. A developer who has never worked in a team that uses Git has no reason to introduce it to their solo practice.
2.2 Deployments Are Manual and Undocumented
The most common deployment process we encounter is: FTP files from the developer's laptop to a shared hosting account. No environment separation between development and production. No deployment checklist. Database schema changes applied manually, often directly on the production database, without a migration file or backup.
The consequences are predictable: database changes that cannot be rolled back, files that are different on the developer's machine and the production server, and no ability to reproduce the production environment locally for debugging.
2.3 Testing Is Absent
Automated testing — unit tests, integration tests, functional tests — is almost entirely absent in the Ghanaian freelance and small-team context. Testing is done manually by the developer clicking through the application. Edge cases that are not part of the happy path are rarely tested. Regressions — bugs introduced when adding new features — are discovered by users in production.
2.4 Documentation Is an Afterthought
Code comments explaining why a particular approach was taken are rare. A README that explains how to set up a local development environment almost never exists. When the original developer leaves or becomes unavailable, the next developer must reverse-engineer the entire application from source code alone.
3. The Business Impact
These are not purely technical problems. They have direct financial consequences:
- Higher bug rates: Software without tests has a consistently higher defect rate after changes. Every new feature is a risk to existing functionality.
- Longer time to fix: Without version control history, diagnosing the cause of a bug requires manual investigation of every recent change. What should take 30 minutes takes half a day.
- Vendor lock-in: When software exists only in a form the original developer can understand and deploy, organisations are dependent on that developer regardless of their performance or price.
- Rebuilding cost: The eventual outcome of unmaintainable software is a full rebuild — in our experience, this typically costs 2–4x the original development budget, often more when the new team must also understand and replicate undocumented business logic. This figure is consistent with what practitioners report anecdotally across the industry.
4. The Minimum Viable Practice Set
We are not proposing that every Ghanaian development team immediately implement CI/CD pipelines, test-driven development, and daily code reviews. We are proposing a minimum viable set of practices that any team of any size can adopt without significant tooling investment:
4.1 Git for All Code
Every project should have a Git repository. Every change should be committed with a message that explains what changed and why. The repository should be hosted on a remote service — GitHub, GitLab, or Bitbucket all have free tiers. This is the single most impactful practice a development team can adopt. It costs nothing and eliminates the "my laptop died and I lost the code" class of disasters entirely.
4.2 Environment Separation
Production and development must be separate. The production database should never be used for development. Configuration that differs between environments (API keys, database credentials, debug flags) should be managed through environment variables, not hardcoded in source files. Secrets should never be committed to version control.
4.3 Database Migrations
Every database schema change — adding a table, adding a column, changing a constraint — should be captured in a migration file that can be run in any environment. This is standard in modern PHP frameworks (Yii2, Laravel) and takes minutes to implement correctly. Without it, the production database and the development database will diverge, and changes cannot be reliably reproduced.
4.4 A Deployment Process
Deployment should be documented, repeatable, and ideally automated. At minimum, there should be a written checklist: pull latest code, run migrations, clear cache, verify the application starts correctly. FTP is not a deployment process. It is a file transfer with no record, no verification, and no rollback capability.
4.5 At Least Smoke Tests
Even without a full test suite, critical paths — user registration, payment processing, login — should be tested after every deployment. This can be a manual process with a documented test script in the early stages. As the team grows, these tests should be automated.
5. Recommendations for Clients Commissioning Software
Organisations that commission custom software are not passive participants in its quality. The following requirements should be standard in any software development contract:
- Source code must be provided in a Git repository that the client controls
- Deployment process must be documented in writing before project acceptance
- Acceptance testing must include documented test scenarios for all critical paths
- All credentials, API keys, and environment configuration must be handed over on project completion — nothing should remain exclusively with the developer
6. Recommendations for Training Institutions
The absence of formal practices in Ghana's development community is, in part, a training failure. Technical curricula that teach programming syntax without teaching version control, deployment, and testing are producing developers who are technically capable but professionally incomplete.
Training programmes should require Git usage from week one — not as an optional module but as the default way all code is managed throughout the programme. Deployment exercises should be part of every project. Students should graduate having deployed a real application to a real server using a documented process — not just having written code that works on their laptop.
7. Conclusion
Ghana's software industry will not achieve its potential while a significant portion of the software it produces is unmaintainable within two years of delivery. The practices required to change this are not expensive or technically advanced. They are standard, well-documented, and supported by free tooling. The barrier is awareness and expectation — from developers, from their employers, and from the clients who pay for the software.
Pinuno Academy integrates formal development practices — Git, migrations, deployment automation, basic testing — into all of its technical training programmes. We believe that producing developers who work correctly, not just developers who work, is the most meaningful contribution we can make to Ghana's ICT sector.