Hiring a Software Company in Abuja: 9 Questions That Predict Failure

Most failed software projects in this market did not fail during the build. They failed at selection, and the build simply revealed it.

These are the nine questions we would ask if we were the client. Several of them are uncomfortable for us to answer too, that is what makes them useful.

1. "Show me something you built that is running right now."

Not a screenshot. Not a case study PDF. A URL you can open on your phone in the meeting.

Anyone can present work. Far fewer can point at something live, still maintained, with the client's name on it. Our own work index is deliberately just a list of live deployments for this reason.

2. "Who specifically will write this code?"

Agencies sell you the senior team and staff the junior one. Ask for names, ask what else those names are working on, and ask what happens if that person leaves mid-project.

3. "What happens in week three when I change my mind?"

Everyone changes their mind. The question is whether the contract handles it or whether it becomes a fight.

A good answer sounds like: "Small changes are absorbed. Anything over half a day gets written up with a cost before we do it, and you approve it." A bad answer is "we're flexible", that means you will be billed by surprise or refused by surprise.

4. "Who owns the code, the domain, and the hosting account?"

You should own all three. If the agency registers your domain on their account, they hold your business hostage without ever intending to.

Ask for the repository to be under your organisation from day one, not transferred at the end. Transfers at the end do not happen.

5. "What does this cost me per year after launch?"

See our full breakdown on pricing. Any quote that ends at launch is incomplete.

6. "How will I know if it is working?"

Analytics, error monitoring, uptime alerts. If nobody is watching, you will find out your checkout has been broken for a week from a customer complaint.

7. "What is your test for done?"

"Done" should be a written list agreed before work starts, not a conversation at the end. Without it, every project ends in a negotiation about whether it ended.

8. "Can you say no to me?"

The most valuable thing a technical partner does is refuse a bad idea. A vendor who agrees with everything is optimising for the invoice, not the outcome, and you will discover the disagreement they should have raised six months later, in production.

9. "What went wrong on your last project?"

The only wrong answer is "nothing".

Every real project has a week where something breaks badly. A team who will tell you about theirs, what broke, what it cost, what they changed, has done the work. A team with a spotless record has either not shipped much or is not being straight with you.

What we would add for Abuja and Lagos specifically

Meet in person at least once. It is cheap here and it filters out a surprising amount.

Check they can invoice properly. If they cannot issue a proper invoice with a TIN, procurement will stall the project regardless of how good the code is.

Ask about power and connectivity. Not a joke, ask how they keep delivery moving through outages. Teams who have solved it have a real answer about redundancy. Teams who have not will treat every outage as an excuse.

Time zones, if you are hiring from abroad. Nigeria is GMT+1, one hour from London, and the working day overlaps Dubai almost completely and US Eastern mornings usefully. That is a genuine structural advantage, and any team here should be able to explain how they use it.