Choosing a software development company is one of the riskier purchases an organisation makes. The product is invisible until late in the project, the quality is hard to judge from a proposal, and switching suppliers halfway through is expensive. In a market the size of Namibia's, you also have fewer suppliers to compare, which makes due diligence more important, not less.
Here is the checklist we would use if we were on your side of the table.
1. Can they show live systems, not only screenshots?
Ask for systems that are in production today, with real users. A live URL, a reference you can phone, or a demo of a system they still support tells you far more than a portfolio of mock-ups.
2. Have they integrated with systems like yours?
Most business software has to talk to something else: a billing platform, an ERP, a payment gateway, a government system. Integration is where projects slip. Ask which systems they have integrated with and what went wrong.
3. Who owns the code and the infrastructure?
You should own the source code, the database, the cloud or hosting accounts and the documentation. Get this in the contract. A supplier who keeps the code or hosts everything under their own accounts makes it very hard to leave later.
4. What happens after launch?
Software needs updates, security patches and small changes for as long as you use it. Ask what a support agreement covers, how quickly they respond, and whether the developers who built the system will still be around.
5. How do they handle security and personal data?
Ask how they manage passwords and secrets, how access is controlled, whether actions are logged, and how they test for common vulnerabilities. If the answer is vague, the system will be too.
6. Will they tell you when something is a bad idea?
A good partner will sometimes recommend building less, buying an existing product, or changing the order of work. A supplier who agrees with everything in the first meeting will usually discover the problems on your budget.
7. How do they estimate, and what is excluded?
Compare quotes line by line. A low quote often excludes testing, documentation, deployment, data migration or training. Ask for the assumptions behind the estimate and what happens if they turn out to be wrong.
8. How often will you see working software?
You should see progress in weeks, not months. Regular demonstrations of working software let you correct course early and cheaply.
9. Is there documentation and a proper handover?
Ask to see an example of the documentation they deliver. At minimum you need a description of the architecture, deployment steps and how to restore from backup.
10. Do they understand the local context?
A Namibian supplier understands local payment providers, connectivity constraints outside the main towns, public-sector procurement and the expectations of local regulators. That context saves time in every workshop.
Warning signs
- No live references, or references you are not allowed to contact.
- The supplier keeps the source code or hosts it under their own accounts.
- A fixed price with no written assumptions.
- No testing, documentation or support in the proposal.
- No working software to show until the end of the project.
We built Myrmidon around the answers above: you own everything we build, every system ships with documentation, and most of our clients keep us on support long after launch. Our case studies list the systems we run in production for Namibian organisations.