How to Review a Software Development Proposal
Custom software differs from a website or an app in one decisive way: it changes how your staff work. A logistics dispatch system, a school management platform or a distributor's inventory system only creates value if people abandon the spreadsheet and use it every day. That means a good proposal is partly a technical document and partly a plan for getting your organisation to adopt something new.
This guide shows how to read such a proposal properly: what each section should say, where cost is commonly understated, and how to compare firms whose documents are structured completely differently.
What a software proposal should contain
A proposal for a custom business system should include:
- A statement of the business problem and the processes affected.
- A module list with a short description of what each module does.
- User roles and what each role can see and do.
- The technical approach: architecture, stack, hosting model, environments.
- Integration list: which existing systems, in which direction, using what.
- Data migration scope: what is moved, cleaned, and what is left behind.
- Reporting requirements: which reports, for whom, at what frequency.
- Acceptance criteria and the user acceptance testing process.
- Training and rollout plan, including how many staff and in which locations.
- Timeline with phases and your obligations.
- Price split into build, licences, infrastructure and support.
- Service level for support after go-live.
- Ownership of code, data and documentation.
- Exclusions and assumptions.
The proposal should also tell you, honestly, whether custom software is the right answer. A firm that recommends buying an existing product for part of the scope is displaying judgement, not weakness. When Should You Buy Existing Software?are? set out that decision.
Does the proposal trace back to your requirements?
If you supplied a requirements document, the proposal should map to it. If you did not, the proposal should propose a discovery phase to produce one, rather than quoting a firm price against assumptions.
Check for traceability in practice:
- Every requirement you listed appears somewhere: in scope, deferred, or explicitly excluded with a reason.
- Nothing appears in the proposal that you did not ask for, unless it is flagged as a recommendation with its own price.
- Ambiguous requirements have been turned into questions rather than quietly interpreted.
A proposal that silently drops three of your fifteen requirements is a preview of how change will be handled later. A proposal that returns a list of twenty clarifying questions is usually the best document in the pile, even if it is uncomfortable to read. How to Create a Software Requirements Documentan quote against.
Modules, user roles and permissions
Most cost disputes in custom software come from role complexity rather than feature count. Adding a second user type can double the work in a module because every screen, permission and report must account for it.
The proposal should present something like:
| Module | What it does | Roles that use it |
|---|---|---|
| Orders | Create, approve, amend and cancel customer orders | Sales officer, sales manager, accounts |
| Inventory | Stock levels per warehouse, transfers, adjustments | Storekeeper, operations manager |
| Invoicing | Generate invoices, record payments, track receivables | Accounts, management |
| Reporting | Sales, stock and receivables reports with date filters | Management, accounts |
| Administration | Users, roles, branches, master data, audit log | System administrator |
Then ask three questions of the role model:
- Can a user belong to more than one role, or to a specific branch?
- Which actions require approval, and by whom?
- Is there an audit log showing who changed what and when?
For Nigerian businesses with branch structures and cash handling, approval workflows and audit logs are usually the difference between a system that reduces leakage and one that merely records it.
Architecture, hosting and deployment
You do not need to evaluate the code. You do need to understand five things.
Where it runs. Cloud hosting (typically USD-priced), a server in your office, or a hybrid. An office server avoids currency exposure but introduces power, cooling, backup and security responsibilities you must staff.
Environments. At minimum a staging environment separate from live, so changes are tested before they touch real data.
Access model. Browser-based, desktop application, mobile app for field staff, or a combination. Field teams in Lagos traffic or rural distribution routes need something that works on a phone with intermittent connectivity.
Offline tolerance. If staff enter data where the network is unreliable, the proposal must say what happens: queue and sync, or simply fail. This is a design decision with real cost.
Backups and recovery. Frequency, where backups are stored, how long recovery takes, and who tests restores. A backup that has never been restored is a hope, not a control.
Ask directly what happens if the vendor disappears: can another firm take over the system with the documentation provided? The honest answer is a good proxy for overall quality.
Integrations and data migration
These two items are where software budgets break.
Integrations. For each one, the proposal should state the system, the direction of data flow, the method (API, file export, database), the frequency, and who owns the credentials. Typical Nigerian integration requests include accounting software, POS systems, payment gateways such as Paystack, Flutterwave, Interswitch or Remita, bank statement imports, SMS providers, and the WhatsApp Business Platform.
The critical question is whether the other system actually has an interface. Many locally used packages do not, and "integration" then means scheduled file exchange with manual steps. That is workable but must be scoped honestly.
Data migration. Ask what is being migrated, from what format, how it is cleaned, who validates it, and what happens to history. A distributor with six years of sales data in three spreadsheets and a legacy package has a data project, not a data task. Indicatively, migration on a mid-sized system can consume 10–20% of the build effort.
Watch for the phrase "client to provide data in the agreed template". That clause moves a substantial workload to your team. Decide who will do it and when.
Acceptance criteria, testing and UAT
Acceptance is what converts "we have finished" into "we agree it is finished".
A strong proposal defines:
- Acceptance criteria per module, written as testable statements.
- Who on your side runs user acceptance testing, and for how long.
- Defect severity levels and the turnaround for each.
- What counts as a defect versus a change request, since that boundary decides who pays.
- A period of parallel running, where the new system and the old process run together before the old one is retired.
Parallel running is frequently omitted from proposals and is often essential. For a payroll or inventory system, running both for one cycle is cheap insurance against discovering a calculation error after you have shut down the alternative.
Training, rollout and change management
Ask how many people will be trained, in which locations, in what format, and what materials you keep.
Realistic elements:
- Role-based sessions rather than one generic demonstration.
- A written or recorded guide per role that a new hire can use in six months.
- A designated internal champion per department, trained more deeply.
- A support window immediately after go-live with faster response times.
- A phased rollout: one branch or department first, then the rest.
Software that staff resist is the most common cause of a failed custom project in Nigerian SMEs, and it is rarely a technical failure. If the proposal treats training as a half-day afterthought on a system replacing everyone's daily routine, raise it before signing.
Support, SLA and the cost of year two
The proposal should state a support arrangement with:
- Hours of cover and channels (phone, email, WhatsApp, ticket system).
- Response and resolution targets by severity.
- What is included: bug fixes, minor changes, user administration, backups monitoring.
- What is chargeable, and at what rate.
- How many hours of enhancement work are included per month, if any.
- Escalation contacts.
Indicatively, annual support and maintenance for custom business software runs in the region of 15–25% of build cost per year, though this varies widely with complexity and the level of service. Confirm whether infrastructure, third-party licences and model or API usage are inside or outside that figure.
Reading the price and total cost of ownership
Compare on three-year total cost, built like this.
| Cost line | Type | Indicative range |
|---|---|---|
| Discovery and requirements | One-off | Often 5–15% of build |
| Design and development | One-off | ₦2,000,000–₦30,000,000+ depending on modules |
| Data migration | One-off | Frequently 10–20% of build effort |
| Training and rollout | One-off | Varies with staff numbers and locations |
| Cloud hosting and infrastructure | Annual | ₦150,000–₦800,000+, usually USD-linked |
| Third-party licences and services | Annual | Varies; often USD-priced |
| Support and maintenance | Annual | Indicatively 15–25% of build cost |
| Enhancements | Annual | Budget a contingency; systems always evolve |
Indicative 2026 ranges; actual quotes vary with scope, vendor and the naira exchange rate. Ask every firm to price the same written scope.
Then compare that three-year total against the alternative: an existing SaaS product priced per user per month in US dollars. For a ten-user team, a subscription product can look cheaper for two years and more expensive by year five, while custom software carries higher upfront risk and complete control. Neither answer is universally right, and the proposal should acknowledge the comparison rather than pretend it does not exist.
Example (hypothetical): two proposals for a Kano distributor
This is a hypothetical illustration, not a Linestech client project.
A fast-moving consumer goods distributor in Kano with three warehouses and eighteen sales representatives wants a system for orders, stock, invoicing and representative tracking, replacing spreadsheets and a legacy desktop package.
- Proposal A: ₦6,500,000, sixteen weeks. Five modules listed as single lines. No role table. No data migration line ("client to supply data"). Integration with the accounting package described as "API integration" with no confirmation the package has an API. Training: one day. Support: "6 months free support". Hosting not mentioned.
- Proposal B: ₦11,200,000 build, plus ₦640,000 estimated first-year infrastructure, plus support at 18% per year. Module and role tables, a described mobile order-capture app with offline queueing for representatives, a two-week discovery phase before the firm commits to a fixed price for phases two and three, data migration scoped at 40 person-days with a validation step owned by the distributor's accountant, a confirmed file-based exchange with the accounting package because no API exists, four weeks of parallel running, role-based training across three locations, and a defined SLA.
Proposal B is 72% more expensive on the build line, and materially cheaper on a three-year view once the distributor prices the work Proposal A pushed onto its own staff, the likely rework on the accounting integration, and support beyond month six. The distributor negotiates Proposal B into phases: discovery first, then orders and stock, then invoicing and reporting, with a go or no-go decision after each.
A comparison framework for software proposals
Score each proposal 0, 1 or 2. Twenty-four or more out of thirty-two is a serious document.
- Business problem and affected processes restated accurately
- Requirements traced: in scope, deferred or excluded with reasons
- Module list with descriptions
- User roles and permissions defined
- Approval workflows and audit trail addressed
- Architecture, hosting model and environments stated
- Offline and connectivity behaviour addressed
- Integrations specified with direction, method and feasibility confirmed
- Data migration scoped with responsibilities
- Acceptance criteria and UAT process defined
- Parallel running considered
- Training and rollout plan with materials
- Support SLA with response targets
- Build, infrastructure, licences and support priced separately
- Ownership of code, data and documentation stated
- Exclusions and assumptions listed
Mistakes buyers make with software proposals
- Comparing build prices instead of three-year totals. The cheap build usually carries the expensive operating model.
- Accepting unverified integrations. If nobody has confirmed the other system has an interface, you are buying an assumption.
- Treating data migration as free. It is a project with its own effort, validation and risk.
- Skipping discovery to save money. Discovery is where scope becomes estimable; skipping it converts a fixed price into a series of change requests.
- Ignoring roles and approvals. They drive cost more than screen count and matter most for control.
- Under-planning training. A system nobody uses is a total loss, not a partial one.
- Leaving the code and database in the vendor's accounts. Who Owns Custom Software Code?.
- Signing a proposal rather than a contract. What Should Be Included in a Software Development Contract?ed.
Conclusion
A software proposal is a plan for changing how your business runs, priced. Read it for the parts that decide adoption: roles and approvals, integrations that have actually been verified, data migration ownership, acceptance criteria, parallel running, training and a support level you can hold the firm to.
Compare on three-year total cost of ownership, insist on a paid discovery phase when requirements are unclear, phase the delivery with go or no-go points, and keep the repository and the database in your own accounts. Those choices matter more than the difference between two build quotes.
If you are assessing proposals for a custom business system, or you need a requirements document and an indicative range before going to market, Linestech can work through the scope with you and set out what the project realistically involves.
Frequently asked questions
Should I insist on a fixed price for the whole system?
For a system of any size, a fixed price for the whole scope before discovery usually produces either an inflated number or a thin scope. A better structure is a paid discovery phase with a fixed price, producing a specification, followed by fixed-price phases quoted against that specification. You keep budget control and the vendor prices something real.
How do I judge whether the estimate is reasonable?
Ask for the estimate broken down by module and by role type, with rough person-days. You will not verify the numbers precisely, but you will see whether the firm has thought in detail. A single figure with no breakdown cannot be assessed by anyone, including the firm that produced it.
What if my requirements are not fully clear yet?
Say so, and ask for a discovery phase rather than pretending otherwise. Unclear requirements do not disappear when you sign a fixed-price contract; they reappear as change requests at a worse moment. Paying for two to four weeks of structured analysis is the cheapest risk reduction available.
Who should be in the room when we review proposals?
The department head whose team will use the system, someone from finance, and whoever will administer it day to day. Owners often evaluate software on reporting and cost while the people who will enter data every day are never consulted, which is how unusable systems get bought.
Should the proposal include source code escrow?
For systems your operations depend on, it is worth discussing. Escrow places code with a third party who releases it under agreed conditions. A simpler and usually sufficient alternative for Nigerian SMEs is to own the repository from day one, with the vendor as a collaborator and code pushed at every milestone.
How long should I expect a mid-sized business system to take?
For a four- to six-module system with integrations and migration, plan in months rather than weeks: commonly four to nine months from discovery to full rollout, including parallel running. Timelines shorter than that normally assume your team makes decisions immediately and that migration and training are trivial.
What should the proposal say about data protection?
It should acknowledge that personal data in the system creates obligations for you under the Nigeria Data Protection Act 2023, and describe access control, encryption in transit, backup handling and data retention. This is not legal advice; confirm your specific obligations with the Nigeria Data Protection Commission or a qualified adviser.
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.
