Software Development Checklist for Nigerian Businesses

Custom software is bought to change how work is done. That makes it a business change project with a technology component, not a technology project with a business component. Roughly speaking, the build is the part most likely to go well; migration, adoption and data quality are the parts most likely to go badly.

This checklist covers the work that sits with you as the commissioning business, from the first process map to the ninety days after go-live. It is written for Nigerian SMEs and mid-sized companies commissioning operational systems: inventory, orders, billing, school administration, clinic management, logistics dispatch, HR and similar.

How to use this checklist

Do not skip Phase 1. Businesses that commission software to fix a process they have never written down usually end up automating the confusion.

Indicative durations for a four- to six-module business system. Smaller systems compress; multi-site programmes run longer.

Name a project sponsor at owner or director level and a project lead who has real time available. Software projects without an internal owner drift.

Phase 1: Map the process and decide build, buy or configure

• Write down the current process step by step, including the paper and WhatsApp parts
• Interview the people who do the work daily, not only their managers
• Identify where errors, delays, leakage and duplication actually occur
• Quantify the cost of the current problem in hours, naira or lost sales
• Decide which parts of the process should change before any software is built
• List the systems already in use: accounting package, POS, spreadsheets, WhatsApp groups
• Check whether an existing product already does this well
• Compare a subscription product against a custom build on a three-year view
• Decide: build custom, buy and configure, or a combination
• Confirm the decision with the department that will use it

Buying is often the better answer for standard functions such as accounting or payroll, and building is often the better answer for the operational process that differentiates your business. A mixed approach is normal. Custom Software vs Off-the-Shelf Softwareftware? cover this decision.

Phase 2: Requirements and data readiness

• Write requirements as testable statements, not wishes
• List modules and what each does
• Define user roles and what each can see, do and approve
• Specify approval workflows and where authorisation limits apply
• List the reports management needs, with fields and frequency
• Specify the audit trail: who changed what and when
• Note non-functional needs: number of concurrent users, record retention, availability expectations
• Mark each requirement as must-have or deferred
• Assess data readiness: where records live now, in what format, how clean they are
• Decide how much history you will migrate and where the cut-off falls
• Name the person who will validate migrated data
• Confirm which integrations are genuinely possible, not assumed

How to Create a Software Requirements Documentnst.

Data readiness deserves particular attention. A business with six years of records spread across four spreadsheets, a legacy package and a stack of files has a data project on its hands before it has a software project.

Phase 3: Budget and total cost of ownership

• Budget the build as a range, not a figure
• Add discovery, usually 5–15% of build
• Add data migration, frequently 10–20% of build effort
• Add training and rollout across all locations
• Add annual infrastructure, usually USD-linked
• Add annual support and maintenance, indicatively 15–25% of build cost
• Add a contingency for enhancements in year one
• Compare the three-year total against the subscription alternative
• Confirm who signs off spending at each phase

Indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate.

Phase 4: Vendor selection and contract

• Send the same requirements document to three to five vendors
• Ask each for an estimate broken down by module
• Check live systems they have built, ideally with a demonstration account
• Call two references, including one from a system running for over two years
• Verify CAC registration and corporate bank details
• Ask what they would advise you not to build
• Compare on three-year total cost, not build price
• Confirm each integration's feasibility has been checked, not assumed
• Sign a contract with a specification annex, acceptance criteria and change control
• Require a repository under your organisation, with code pushed at each milestone
• Agree the support SLA and a rate card for future work
• Include transition assistance on exit, with data export formats defined
• Keep a retention holdback until the warranty period ends

How to Review a Software Development Proposala Software Development Contract? cover these two steps in depth.

Phase 5: Discovery, design and environments

• Pay for a discovery phase if requirements are not fully settled
• Confirm you own the discovery output and may share it with other vendors
• Review and approve the data model and module design
• Walk the proposed screens with the staff who will use them
• Confirm the architecture and where the system will be hosted
• Confirm separate development, staging and production environments exist
• Decide the access model: browser, desktop, mobile for field staff
• Decide offline behaviour for staff working where the network is unreliable
• Agree backup frequency, retention and who tests restores
• Agree security measures: role-based access, password policy, session timeouts, audit log
• Confirm live personal data will not be used in test environments without anonymisation
• Approve the phased delivery plan with go or no-go points

Phase 6: Build, migration and integration

• Review each module on staging as it is delivered, with its real users
• Test against the acceptance criteria in the specification annex, not by impression
• Keep a defect register with severity levels
• Approve payments only against accepted deliverables
• Start data cleansing early, in parallel with the build
• Run a trial migration and check record counts and totals against the source
• Have your accountant or department head verify migrated financial figures
• Confirm each integration with a live test, not a demonstration
• Document any manual steps that remain where an integration is file-based
• Confirm reports produce numbers that match the existing process
• Track changes formally: written request, estimate, written approval
• Hold a weekly project meeting with a written record

Migration failures are usually discovered at the worst moment. A trial migration two months before go-live is the single most useful risk control in this phase.

Phase 7: UAT, parallel running and training

• Nominate testers from every role, and free their time formally
• Give testers scripted scenarios drawn from real work
• Run a UAT window of 10–20 working days
• Log defects centrally with severity, not in individual messages
• Agree what is a defect and what is a change request before testing starts
• Run the new system in parallel with the current process for at least one full cycle
• Compare outputs: invoices, stock balances, payroll figures, fee schedules
• Train by role, not in one generic session
• Appoint and train a champion in each department
• Keep written and recorded training materials for future staff
• Prepare a cut-over plan naming the date, the freeze period and the fallback
• Confirm the support arrangement is active from day one of go-live

Parallel running is frequently cut to save time and is the control most worth keeping. For payroll, billing or inventory, one cycle of comparison catches calculation errors that no amount of testing on invented data will surface.

Phase 8: Go-live and the first 90 days

• Go live at the start of a cycle, not mid-month
• Avoid going live immediately before a peak trading period
• Have vendor support available on site or on call for the first days
• Freeze changes for the first two weeks except critical fixes
• Monitor usage: are staff actually entering data, or keeping the old spreadsheet?
• Hold a daily stand-up for the first week, then weekly
• Log every issue, including complaints about usability
• Fix the top three friction points quickly; early wins drive adoption
• Decommission the old process formally once parallel running is complete
• Confirm backups are running and test one restore
• Complete handover: code, documentation, credentials, deployment instructions
• Review against the Phase 1 problem: has the cost, delay or leakage reduced?
• Plan the first enhancement release from real usage, not from the original wish list
• Diarise the support renewal and the rate card review date

What changes for Nigerian software projects

Adoption is the main risk. Staff accustomed to paper, Excel and WhatsApp will revert under pressure unless the system is faster for them, not only better for management. Design for the data-entry clerk, not only for the dashboard.

Power and connectivity shape the access model. If branches lose power or connectivity regularly, a purely online system will create gaps. Consider offline capture with sync, and budget for it honestly.

Infrastructure is USD-priced. Cloud hosting and licences move with the exchange rate. Decide whether that exposure is acceptable or whether an on-premises server, with its own power and maintenance obligations, suits you better.

Integration with local packages is often file-based. Many accounting and POS products used in Nigeria have no open interface. Confirm before scoping, and accept scheduled file exchange where that is the reality.

Approvals and audit trails matter commercially. Where cash, stock and discounts pass through many hands, authorisation limits and an audit log are often the features that pay for the system.

Data protection duties sit with you. Systems holding customer, patient, pupil or staff data engage the Nigeria Data Protection Act 2023. Address access control, retention and breach handling in the contract, and confirm your obligations with the Nigeria Data Protection Commission or a qualified adviser.

Tax and contracting practicalities. Service invoices raise VAT and withholding tax questions; confirm the position with your accountant or the Federal Inland Revenue Service. Contract with the CAC-registered entity and pay into a corporate account.

Example (hypothetical): a Benin City school group

This is a hypothetical illustration, not a Linestech client project.

A school group in Benin City running three campuses wants a single system for admissions, student records, fee billing, payment reconciliation and results.

• Phase 1. Process mapping reveals fee reconciliation is the real problem: bursars match bank transfers to students manually, and every term ends in disputes. Admissions and results are secondary.
• Phase 2. Requirements written with fee billing as the first module. Data assessment finds student records in two spreadsheets per campus with inconsistent identifiers, requiring a cleansing exercise before anything else.
• Phase 3. Three-year budget approved: ₦8,500,000 build across three phases, ₦520,000 annual infrastructure, support at 18%, plus ₦600,000 for data cleansing using existing staff overtime.
• Phase 4. Vendor selected on the strength of a comparable system and a frank statement that results processing should wait for phase three.
• Phase 5. Discovery confirms an automated bank-statement import is feasible using scheduled file upload, since the school's bank offers no direct interface at its account tier.
• Phase 6. Fee billing delivered first. A trial migration shows 11% of student records have duplicate or missing identifiers, caught eight weeks before go-live.
• Phase 7. One full term is run in parallel. Bursars compare system-generated balances with their own ledgers weekly.
• Phase 8. Go-live at the start of a new term. Reconciliation time per campus falls substantially in the first term, which is the measure the group set in Phase 1.

The project succeeded because Phase 1 identified the real problem. A group that had started from "we need a school management system" would likely have built admissions and results first, and still had the fee dispute.

Where software projects usually fail

• Automating an unexamined process. Fix the process first, then build.
• Skipping discovery. Fixed prices quoted against vague requirements become change requests.
• Underestimating data. Cleansing and migration routinely take longer than the module that consumes the data.
• Assuming integrations exist. Confirm the interface before it is in the scope.
• Training as an afterthought. Adoption failure wastes the entire investment, not part of it.
• No parallel running. Errors then surface after the old process has been retired.
• Going live at a peak. Never at term start for schools, month end for finance, or festive season for retail, unless the cycle demands it and support is on site.
• Leaving the code and data in the vendor's accounts. Who Owns Custom Software Code?.
• No internal owner after go-live. Systems need someone accountable for master data, users and improvements.

Conclusion

Custom software succeeds when the business does its own work properly: mapping the process before automating it, writing requirements that can be tested, assessing data honestly, budgeting on a three-year view, and investing in migration, parallel running and training rather than treating them as the vendor's problem.

Run the phases in order, hold each gate, review modules with the people who will use them, and keep the code, the data and the accounts in your own name. Do that and the system becomes an asset rather than a dependency.

If you are planning a custom system and want help turning a process map into requirements and an indicative budget, Linestech can work through the scope with you.

Frequently asked questions

How do I know whether to build custom software or subscribe to a product?

Compare three-year total cost and fit. If your process is standard, a subscription product configured well is usually cheaper and faster. Build when the process is genuinely specific to your business, when per-user subscription costs scale badly for your headcount, or when the product you need does not handle Nigerian realities such as bank-transfer reconciliation or your fee structures.

How long should a mid-sized business system take?

For four to six modules with migration and integrations, plan four to nine months from discovery to full rollout, including parallel running. Phased delivery lets you get value from the first module earlier, often within two to three months, while later modules continue.

Who should be on the project team internally?

A sponsor at owner or director level, a project lead with time available, a champion from each affected department, and someone from finance where money is involved. The people who will type into the system every day must be represented, not just consulted at the end.

What if staff resist the new system?

Treat it as a design problem before a discipline problem. Usually the system is slower for them than the old method, or it asks for data they do not have at the moment of entry. Watch three staff use it for an hour; the friction is normally obvious. Then remove steps, pre-fill what you can, and train the champions properly.

Should we go live all at once or module by module?

Module by module is safer for most businesses, provided the modules can stand alone. Start with the one that solves the problem you quantified in Phase 1. A single big-bang go-live across all modules and all sites concentrates risk on one day and is rarely worth it below enterprise scale.

How much should we keep aside for changes after go-live?

Budget a contingency for year one, because real usage always produces sensible change requests. A rate card agreed in the contract keeps that spending predictable. Resist changing anything in the first two weeks, when complaints are often about unfamiliarity rather than design.

What documentation should the vendor hand over?

An architecture and environment overview, database schema documentation, API documentation, deployment and release instructions, administrator and end-user guides, and credentials for every account. Make these named deliverables tied to the final milestone and the retention release.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Corporate Affairs Commission (CAC)
• Nigeria Data Protection Commission (NDPC)
• GitHub documentation