How to identify the right technologies for your business

The short answer

Organisations often choose technology the wrong way round: someone sees a product demo, and the business adapts to the tool. A better method has five steps:

1. Map the business capabilities you need to support.
2. Take stock of what you already have.
3. Set evaluation criteria that reflect your priorities and constraints.
4. Shortlist and score options, including "use what we have" and "do nothing".
5. Test with real work before committing, and record the decision.

The result is a technology stack, the combination of platforms, applications, infrastructure and tools you run on, that fits together and can be supported over time.

Step 1: map business capabilities

List what the organisation must be able to do, not which software it wants. For example: take and fulfil orders, manage stock across locations, bill clients by project, onboard employees, collect payments by bank transfer and card, report to funders or regulators. For each capability, note how it works today, what goes wrong and how important it is.

This keeps the discussion on outcomes and makes it easier to compare very different options, such as extending your ERP, buying a SaaS tool or building a custom application. See build, buy or integrate.

Step 2: take stock of what you already have

Inventory current systems, licences, contracts, integrations and data. Many organisations already pay for capabilities they do not use, especially in Microsoft 365, Google Workspace, their accounting system or ERP. Also note which systems are approaching end of support; vendors publish these dates, for example in Microsoft's lifecycle policy pages (Microsoft Learn).

Step 3: set evaluation criteria

Agree the criteria before looking at products, and weight them. Typical criteria:

• Functional fit. How much of the required capability works out of the box, and how much needs configuration or custom work?
• Integration. Documented APIs, existing connectors to your current systems, and clear rules on which system owns which data.
• Security. Multi-factor authentication, single sign-on, role-based permissions, audit logs, encryption, and the vendor's record of fixing vulnerabilities. For custom web applications, ask how the developer addresses the risks in the OWASP Top 10 (OWASP).
• Support lifecycle and release cadence. How long each version receives security updates, and how often you must upgrade. Unmaintained versions become a risk: WordPress notes that older versions are not maintained with security updates (WordPress). Active open-source projects publish releases openly, as ERPNext does on GitHub (ERPNext releases).
• Data location and data protection. Where data is stored and processed, who can access it, and whether your contract gives appropriate safeguards when personal data is processed outside Nigeria, as the Nigeria Data Protection Act 2023 (NDPA) requires (Nigeria Data Protection Commission).
• Resilience to local conditions. Does the product keep working through power and connectivity interruptions, with offline tolerance, sensible sync and light pages on mobile networks? Cloud tools depend on your links, so plan UPS or inverter cover and a second internet connection alongside the choice.
• Skills and support availability. Can you hire or contract people who know this technology in Nigeria? Is vendor or partner support available in your time zone?
• Accessibility and usability. Support for accessibility standards (we recommend WCAG 2.2 AA as good practice) and good behaviour on phones, where many of your users will work.
• Total cost of ownership. Licences or hosting, implementation, integrations, training, administration, upgrades and eventual exit, over at least three to five years, as estimates in naira (or US dollars where a licence or service is priced in dollars). Note which items are dollar-priced, because exchange-rate movements change their cost in naira.
• Portability. Can you export all your data in a usable format if you leave?

Step 4: shortlist and score

Build a shortlist of two to four options, always including the option of improving what you already have. Score each against the weighted criteria. Involve the people who will use and support the system, not only those who will approve the budget. Check references from organisations of similar size and sector.

Step 5: test before you commit

Run a proof of concept or structured trial using your own data and your hardest real scenarios: the unusual order, the multi-currency invoice, the approval with three exceptions. Test integrations and permissions, not just screens. Confirm that the result can be supported by your team or provider.

Record the decision in a short note: what you chose, why, which alternatives you rejected, and what would make you revisit the choice. This saves time when people change or questions arise later.

Common mistakes

• Choosing by feature count. More features mean more to configure, secure and train. Choose the option that does what you need well.
• Ignoring integration. A good product that does not connect to your other systems creates re-keying and errors.
• Following trends without a need. New technologies such as blockchain or generative AI are worth adopting when they solve a defined problem better than simpler options.
• Underestimating change. Training, process redesign and data clean-up often cost more effort than the software.
• Standardising too late. Every extra tool adds licences, logins and security exposure. Retire overlapping systems.

Limitations

No method removes uncertainty. Vendors change pricing, products are acquired and requirements evolve. Review your stack annually against the same criteria, and plan replacements before systems reach end of support.

Next step

Our IT consulting and advisory service runs this process with you, from capability mapping to vendor scoring and proof of concept. When no product fits, our custom software development team can build what you need. To choose a partner for implementation, read how to choose a technology implementation provider.

Sources and further reading

Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.

1. Microsoft Lifecycle Policy, Microsoft Learn
2. ERPNext releases, Frappe (GitHub)
3. Hardening WordPress, WordPress Developer Resources
4. OWASP Top 10, OWASP Foundation
5. Nigeria Data Protection Act 2023 and GAID 2025, Nigeria Data Protection Commission

This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.