A software procurement decision can affect a business for years. The most expensive mistake is often not choosing an inexpensive supplier; it is choosing without defining the business problem, acceptance criteria, ownership and maintenance responsibilities.
Whether the project is a company website, customer portal, internal system or complex industrial application, evaluate the supplier’s ability to deliver the entire operating system around the software: requirements, design, security, integration, deployment, documentation, support and exit.
1. Prepare a problem statement before requesting prices
Describe who uses the current process, what happens today, where errors or delays occur, and what successful change would look like. Distinguish essential requirements from preferences. A request such as “we need a modern platform” is too vague to compare suppliers meaningfully.
Instead: “Our 18 branches update event information independently, creating outdated public schedules. We want a centrally governed system that lets authorized branch editors update their own pages and allows the central team to revoke access.” This creates measurable technical and operational expectations.
2. Evaluate relevant evidence rather than portfolio size
A team that builds attractive brochure websites may be excellent for marketing work but lack the experience needed for industrial data systems. Conversely, a technically sophisticated engineering team may be unsuitable if it cannot communicate or deliver usable interfaces.
Ask for demonstrations of work close to your problem. When confidentiality prevents showing client data, request an authorized sanitized demo, architecture explanation or public reference. Establish whether projects are prototypes, installed systems, limited pilots or production deployments. These stages are not interchangeable.
3. Assess six delivery dimensions
Scroll horizontally if needed to read all columns.
| Dimension | Questions worth asking |
|---|---|
| Discovery | How will you resolve unclear requirements? |
| Engineering | How are data, authorization, integrations and failures designed? |
| Design | Can representative users complete real tasks? |
| Quality | What automated and manual tests support acceptance? |
| Operations | Who handles backups, incidents, monitoring and updates? |
| Ownership | What can we export or maintain if the relationship ends? |
A supplier who promises every feature quickly without investigating constraints deserves careful scrutiny. So does a supplier who insists on complex infrastructure for a simple website.
4. Demand an explicit security and data model
At minimum, clarify identity, roles, permission checks, data classification, encryption as appropriate, secret management, backups, restore testing, security updates and incident reporting. For multi-tenant systems, ask how customer data is isolated server-side. For industrial sites, clarify read-only integration boundaries and what happens during connectivity loss.
Zimbabwean organizations handling personal information need to consider the Cyber and Data Protection Act [Chapter 12:07] and related applicable obligations. Ask who is controller or processor where relevant, where data is stored or processed and what contractual obligations apply. Seek legal advice for interpretation, particularly cross-border processing and sector-specific requirements.
5. Review the real project economics
Compare a multi-year estimate: discovery, build, migrations, third-party subscriptions, hosting, security, support, modifications and potential exit costs. A low one-time quote may omit essentials. A high quote may include complexity you do not need.
Request a staged delivery plan with usable acceptance criteria. For uncertain projects, an initial discovery or technical proof of feasibility can reduce risk—but it should have bounded scope and useful deliverables, not become an indefinite paid workshop.
6. Make acceptance objective
“Website works properly” is not an acceptance criterion. Examples include: an authorized branch editor can update a page; another branch cannot access its private draft; all public pages render on specified mobile widths; an exported dataset is complete; a backup can be restored; and agreed failure paths produce understandable feedback.
Have suppliers demonstrate test results and important user journeys. If a feature depends on third-party approval or external services, explicitly mark the dependency and acceptance condition.
7. Get maintenance and exit terms in writing
Clarify source-code ownership or licensing, domain ownership, hosting accounts, access to repositories, backups, update schedules, incident response, documentation and handover. Not every client must own the vendor’s platform source code, especially for a reusable SaaS product, but every client should understand data portability, contractual rights and service continuity.
Supplier evaluation checklist
- The proposal addresses our documented problem.
- Relevant deliverables are demonstrated with accurate status labels.
- Security, access control and data ownership are clear.
- Costs include maintenance, hosting and change requests.
- Timelines have milestones and acceptance tests.
- Integrations and external dependencies are identified.
- Support response procedures are written down.
- We can retrieve our data in usable formats.
- Client responsibilities are explicit.
Frequently asked questions
Should I choose the cheapest quotation? Price alone is not an adequate measure. Compare scope, excluded items, long-term costs and risk.
Do I need a full specification before contacting developers? Not a complete technical design. A credible business problem, target users and constraints are enough for structured discovery.
Should a software company also handle hosting? It can, but clarify ownership, renewals, backups, access and exit. Convenience should not mean losing control of your domain or information.
Is local support important? It can be important for training, field deployment, legal context and urgent on-site work. Capability and reliability remain more important than location alone.
Related reading
See Excel vs ERP vs Custom Software, Commissioning Custom Software Mistakes and Securing Business Data in Zimbabwe.
