Questions to Ask a Software Development Company Before Signing

Custom software is bought once and lived with for years. The questions that protect you are not about programming languages; they are about requirements, data, testing, documentation, support and ownership — the areas where the gap between a good firm and a poor one is widest, and where the consequences surface long after the invoice is paid.

This article is a written question bank you can send to two or three shortlisted firms. It complements the selection process itself, which covers shortlisting, scoring and reference checking. Here the focus is narrower: what to ask, what a strong answer sounds like, and what should worry you.

How to run the question process

Four rules turn this list into a useful exercise rather than an interrogation.

1. Send the same questions to everyone on the shortlist, in writing, with a response deadline. Identical inputs produce comparable answers.
2. Score the answers, ideally with a colleague scoring independently. A simple 1-to-5 per section is enough to expose where a firm is strong and where it is improvising.
3. Follow up verbally on the two weakest sections. How a firm handles a probing follow-up is itself information.
4. Keep the answers. They become the basis of the scope discussion and, later, the contract.

Expect a good firm to push back on some questions, to say "that depends, and here is what it depends on", and to ask you several questions in return. That exchange is the point. A vendor who answers forty questions with forty unqualified yeses has not engaged with your project.

Requirements and discovery

Why discovery is worth paying for. For anything above roughly ₦3,000,000, a paid discovery phase produces a written specification you own even if you then hire someone else. It also shows you how the team writes, questions and documents — the qualities that determine whether the project succeeds. It is the cheapest risk reduction available in custom software.

A question worth asking twice: "Which parts of our request would you advise us not to build?" The answer separates firms thinking about your outcome from firms thinking about scope value.

Architecture and technology choices

1. What technology will you use, and why is it right for this system? Expect reasoning about the problem, maintainability and the availability of developers who know it, not enthusiasm for a framework.
2. Can you explain the architecture in business terms? If they cannot, communication will be difficult for years.
3. How many other Nigerian developers could maintain this if you were unavailable? Unusual technology choices narrow your options later.
4. Web, mobile or both, and why? Establish how staff will actually access the system: desktop in an office, phone in a warehouse, tablet on a site.
5. How will it behave with poor connectivity or during a power interruption? For field, branch or warehouse operations this is a design requirement, not a detail.
6. How will it handle growth? What happens at ten times the current data volume or users.
7. What third-party services will it depend on? Each one is a cost, a dependency and a potential point of failure.
8. What are the limitations of your proposed approach? A firm willing to state trade-offs is a firm that has made them before.

Integrations and data migration

Data migration is the most commonly underestimated part of a Nigerian custom software project, and the most common cause of a go-live being postponed.

1. What systems must this connect to, and have you integrated them before? Accounting software, payment gateways, POS terminals, bank statements, messaging platforms, logistics providers.
2. How will our existing data be moved? Spreadsheets, an old database, paper records — each requires different effort.
3. Who cleans the data? This is a large task and it is frequently excluded from quotes. Confirm in writing who does it.
4. How will migrated data be validated? Ask for a reconciliation approach, not an assurance.
5. Will we run both systems in parallel? For business-critical systems a parallel period is normal and should be planned.
6. What happens to historical records? Whether they are migrated, archived or left in the old system.
7. What is the rollback plan if go-live fails? Ask what "fails" means and who decides.
8. Is migration included in the price, and for how many records? A volume-based answer is a good sign.

Team, delivery process and communication

The single-developer question matters most in the Nigerian market. Skilled engineers relocate and change jobs. If the answer is that one person holds all the knowledge and there is no documentation requirement, you are buying a system with an expiry date tied to that person's career.

Testing and quality assurance

1. Who tests the software, and is it someone other than the person who wrote it? Separate testing catches far more.
2. What types of testing are included? Functional, integration, user acceptance, performance, and testing on the actual devices your staff use.
3. Will our staff test it before launch? User acceptance testing by real users is where the important problems surface.
4. What is the process for reporting and fixing defects? A tracked list with severity levels, not a WhatsApp thread.
5. What defect level is acceptable at launch? An honest firm will tell you that zero is unrealistic and explain how severity is classified.
6. Is the system tested on low-end Android devices and slow connections? For most Nigerian deployments this is where real problems appear.
7. Is testing a separate line item in the quote? If it is absent from the price, you are the testing department.
8. How long is the testing phase? A plan with no testing window is a plan that will slip.

Security, access and compliance

• How is access controlled by role? Who can see, edit, approve and delete.
• Is there an audit trail of who did what? Essential for stock, finance, patient and student records.
• How are passwords and sessions handled? Expect a clear, current answer.
• How is data encrypted in transit and at rest?
• How often are backups taken, where are they stored, and have restores been tested? An untested backup is an assumption.
• Who at your company can access our production data, and how is that logged?
• How is access revoked when your developer leaves?
• How does the system support our obligations under the Nigeria Data Protection Act 2023? Obligations sit with you as the business collecting personal data; verify current requirements with the Nigeria Data Protection Commission.
• For financial or health data, what sector requirements have you worked with? Confirm with the relevant regulator rather than relying on a vendor's reading.

Hosting, environments and running costs

1. Where will the system be hosted, and in whose account? Your own cloud account is strongly preferable to a vendor-controlled one.
2. What will hosting cost annually? Business application hosting commonly runs ₦150,000–₦800,000 or more per year, and larger systems exceed that.
3. Which running costs are in US dollars? Cloud hosting, monitoring, email delivery, mapping and AI services typically are, which exposes your budget to exchange-rate movement.
4. Will we have separate development, testing and production environments? Changes tested in production are changes tested on your business.
5. What is the expected uptime, and what monitoring exists? Ask who receives alerts and at what hours.
6. What is the disaster recovery plan? How long recovery takes and how much data could be lost.
7. What is the total first-year cost including licences and subscriptions? One figure, with assumptions listed.
8. What annual cost should we budget from year two? Maintenance commonly runs 15–25 per cent of build cost per year, plus hosting and third-party services.

Source code, documentation and handover

Test this concretely: ask to see redacted documentation from a previous project. Firms that document well can show you within a day. Firms that do not will explain why documentation is unnecessary, which is the answer that should concern you most in this entire list.

Training, launch and the first 90 days

1. What training is included, for how many people, and in what format? Recorded sessions and written guides outlast a single live walkthrough.
2. Will you train administrators separately from ordinary users? They need different things.
3. What support is provided during the first weeks of live use? This is when questions peak and when staff either adopt the system or quietly revert to spreadsheets.
4. What is the warranty period, and what counts as a defect versus a change? Thirty to ninety days is common; the definition matters more than the duration.
5. How will we know the system is working as intended? Agreed acceptance criteria, measured.
6. Who handles resistance from staff? Adoption is a management task, but a vendor who has seen it before will help structure the rollout.
7. Will the launch be phased or all at once? Phased rollouts by branch or module reduce risk considerably.
8. What happens if we need to pause the rollout? A defined process beats an argument under pressure.

Support, maintenance and change control

1. What does the support agreement cover, and what is billed separately? Bug fixes, small changes, new features and emergency response are different things.
2. What are the response times by severity, and during what hours? Written commitments, not intentions.
3. How is support requested? A ticketing route with a record beats a personal phone number.
4. What does maintenance include beyond fixing bugs? Library updates, security patches, hosting management, monitoring and backups.
5. How are new features requested, estimated and approved? A written change-control process protects both sides.
6. What is your hourly or daily rate for out-of-scope work? Published rates prevent negotiation at every request.
7. What happens if we do not take a maintenance plan? Ask what the system needs regardless and what the ad hoc rate is.
8. What notice is required to end support, and what handover is provided? Agree it before you need it.

Example (hypothetical): a manufacturer replacing a legacy system

This is an illustrative scenario, not a Linestech client.

A manufacturer in Ogun State runs production scheduling and inventory on a system built in 2016 by a developer who is no longer contactable. Three firms are shortlisted and sent the same thirty questions.

What the answers reveal:

• Discovery. Firm A proposes building from the existing system's screens. Firm B proposes two weeks of discovery including time on the factory floor, because the current system is bypassed daily by supervisors using paper. Only B has asked why.
• Migration. Firm A's quote includes "data migration" as one line. Firm B specifies record volumes, a cleaning responsibility, a reconciliation method and a two-week parallel run. Firm C excludes migration entirely, which is at least honest.
• Continuity. Firm A names one developer. Firm B names three people, states who covers whom, and commits to documentation as a deliverable.
• Testing. Firm A includes no testing phase. Firm B includes user acceptance testing with named factory staff and testing on the low-end tablets used on the floor.
• Running costs. Firm B provides annual hosting and subscription estimates, flags which are dollar-denominated, and recommends a budget range rather than a fixed figure.
• Documentation. Asked for a redacted sample, Firm B sends one the next day. Firm A explains that documentation is unnecessary because the code is clear.

Firm B is roughly 60 per cent more expensive than Firm A. The difference is discovery, migration, testing, documentation and warranty — which is to say, the difference is whether the system will still be usable in 2031.

Answers that should worry you

• "We do not need discovery, just give us the requirements." Your requirements are incomplete; everyone's are. Discovery is where that is found out cheaply.
• "Documentation is not necessary." It is the difference between an asset and a dependency.
• "You will get the code at the end." Repository access from day one is standard and protects you if the relationship ends early.
• "Testing is included in development." Ask who tests and how. If the answer is "the developer checks their work", budget for defects.
• Silence on data migration. The most common cause of delayed go-lives in Nigeria.
• "Hosting is on our account, do not worry about it." Worry about it. Accounts should be yours.
• No written change process. Every project changes; without a process, each change becomes a negotiation.
• No maintenance offer. A firm that does not want to support what it builds is telling you something.
• A quote far below the others. Not dishonest, usually — just answering a smaller question. Normalise the scope before comparing.
• Reluctance to provide references. Fifteen minutes with a past client is the highest-value check available.

Conclusion

The written question bank is the cheapest due diligence available when buying custom software. It costs an hour to prepare, it forces three firms to answer the same things, and it surfaces the gaps — discovery, data migration, testing, documentation, running costs and support — that account for most failed projects in the Nigerian market.

Send the questions, score the answers, probe the weakest sections verbally, and carry what you learn straight into the contract. Then start with a paid discovery phase, because the specification it produces is yours whatever you decide next.

If you are shortlisting firms and want written answers on discovery, migration, testing, documentation, ownership and running costs before any commitment, Linestech provides that detail as standard on custom software proposals for Nigerian businesses.

Frequently asked questions

How many questions should I actually send?

Twenty-five to thirty-five, selected for your project. Always include discovery, data migration, testing, source code ownership, documentation, running costs and support. Firms with good process welcome a structured list because it reduces disputes for them as well.

What is the difference between this and choosing the company?

Choosing the company is the overall process: defining the brief, shortlisting, scoring, reference calls and contracting. This list is the content of one step within it — the written questions you use to compare shortlisted firms on the same basis.

Should I ask these of a freelancer too?

Yes, adapted. Drop the team-structure questions and sharpen the continuity ones: who else can access the code, what documentation will I receive, what happens if you become unavailable for a month. Individual developers can deliver excellent work; the risk is concentration, and it needs managing explicitly.

Is it reasonable to ask for sample documentation?

Entirely. Redacted documentation from a past project is a routine request and one of the most informative things you can see. Firms that document well produce it quickly; firms that do not will explain why it is unnecessary.

How do I evaluate technical answers I do not understand?

Judge the explanation rather than the technology. A competent firm can explain the consequence of a technical choice in business terms — cost, speed, who can maintain it, what happens at scale. If they cannot, that is a communication problem you will live with for years.

What if a firm refuses to answer in writing?

Take it as a decision. Written answers protect both parties, and refusal usually signals either disorganisation or a wish to keep scope flexible in their favour.

Should I ask about their financial stability?

For a project running six months or more, yes, and it is a normal commercial question. Verify the CAC registration, ask how long they have traded, roughly how many people they employ, and whether they have other clients on retainer. You are betting on the firm existing at the end of the build.

When should I involve a lawyer?

Once you have selected a firm and before signing, for any contract of significant value. Use the answers you collected to shape the contract, particularly on source code ownership, acceptance criteria, warranty, support terms and exit. This article is commercial guidance, not legal advice.

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)
• Cloudflare Learning Center
• GitHub documentation