Choosing a Software Development Company in Lagos — 12 Questions to Ask Before You Sign

If you’ve been quoted ₦500k for a “world-class fintech app” and ₦40M for the same scope by a different agency, you’re not going crazy — the Lagos software market is enormously varied. Brilliant teams sit alongside template-resellers, freelancers moonlighting between day jobs, and outright ghost agencies. Picking the wrong one costs you the project, the budget, and twelve months you can’t get back.

This is the screening checklist we wish every buyer used before signing a software development contract in Lagos. None of these questions are gotchas. The good vendors will answer them confidently. The bad ones will get vague.

The 12 questions

1. “Can you show me the architecture diagram for a comparable past project?”

Anyone who has built a serious system has a whiteboard photo or a Lucidchart of the architecture. They should be able to walk you through services, databases, queues, and integrations of one past project — without naming the specific client (NDA-friendly).

If they can’t produce one, they probably haven’t built systems that needed one.

2. “Who will actually write the code?”

Some Lagos agencies sell senior consultants in pitches and put juniors on the keyboard. Ask explicitly: who, by name, will be on the team? What’s their experience? Can you meet them before signing?

The first 30 minutes you spend with the engineers tells you more than the first 3 hours you spend with the salesperson.

3. “How do you handle production incidents?”

Production breaks. The right answer is something like: “We have a Slack channel with the client, a runbook for common incidents, an on-call rotation, and we use Sentry for error tracking. Severity-1 incidents get a response within 30 minutes.”

The wrong answer is silence, or “we’ll fix bugs when you report them.”

4. “Will you transfer the code and infrastructure to me on demand?”

The code, the database, the cloud accounts, the domain registrar credentials, the third-party API keys — all of it. If the vendor’s answer is “you can have it but it’s licensed to us, so…” that’s a red flag.

You should own everything. The vendor should retain only what they explicitly licensed (rare in custom builds).

5. “What’s your testing strategy?”

Levels of acceptable answers:

• Bad: “We test by clicking around before release.”
• OK: “We have integration tests on the critical paths.”
• Good: “We run unit tests on business logic, integration tests on the API surface, and end-to-end tests on the critical user flows. CI fails the build if tests fail.”
• Great: All of the above plus a UAT phase with the client and a pen-test before fintech launches.

6. “How do you handle scope changes?”

Change is the rule, not the exception. The right vendor has a documented change-request process: written request, impact assessment (cost + timeline), client approval, then build. The wrong vendor either says “no problem we’ll add it” (then disappears) or charges three times the rate for any addition.

7. “What happens at the end of the engagement?”

Three things should happen at the end:

• Code handover — the codebase in your repository.
• Documentation — at minimum, README, deployment guide, environment variables explained, runbook for common ops tasks.
• Knowledge transfer — a session (or three) where the vendor walks your team or your future maintainer through the codebase.

If the vendor’s answer to “what happens at the end” is “we keep maintaining it forever, just pay us monthly,” that’s a lock-in trap.

8. “Can you walk me through one of your recent security reviews?”

Vendors who take security seriously can describe how they handled it on a recent project — passwords hashed with Argon2id, secrets in environment variables not config files, signed URLs for private storage, prepared statements not string concatenation, security headers, HTTPS-only.

Vendors who can’t are either inexperienced or dishonest about it. For fintech and healthcare, that’s disqualifying.

9. “How do you deploy to production?”

The minimum bar in 2026 is: a CI pipeline that runs on every push, ships to staging automatically, and to production with a single approval click. SSH-and-rsync is acceptable for small static sites; for anything serving real traffic, expect a real CI/CD setup.

10. “Who owns the IP on what you build?”

The contract should be explicit:

• Custom code written for the project: assigned to the client on full payment.
• Pre-existing libraries the vendor brings: licensed to the client perpetually for use in the deliverable.
• Open-source code: governed by its respective licence, which the client must comply with.

If the vendor wants to retain ownership of the custom code “to use in future projects,” that’s a hard no.

11. “Can you give me three reference clients I can call?”

Good vendors say yes. They text three former clients, ask if it’s OK, and put you on a call within a week. Bad vendors send “case study PDFs” and avoid the question.

When you call the references, ask three things: Did they ship on time? Did they ship on budget? Would you hire them again?

12. “What’s the project you turned down most recently, and why?”

This is the killer question. Vendors who say yes to every project are commodity body-shops. Vendors who say no — to wrong-fit clients, to underspecified scope, to unrealistic timelines — are operating like a real firm.

The good answer sounds like: “We turned down a NGN 8M fintech build last month because the client wanted card issuance but had no banking partner lined up. We told them what to do first and offered to come back when they were ready.”

Red flags to walk away from

• No written proposal, just a price and a handshake.
• No architecture diagram or technical scope, just a feature list.
• They start coding on day 1 without discovery, design, or scope sign-off.
• No references, or references who give weirdly cautious answers.
• Their portfolio is mostly redesigns of WordPress templates but they’re quoting you a fintech build.
• No NDA offered for sensitive projects.
• They demand 100% upfront, or the milestone schedule is heavily front-loaded.
• They don’t ask hard questions in the discovery call. Good vendors interrogate the brief.

Green flags to lean into

• They push back on parts of your scope with reasoning. (“We’d cut feature X for the MVP because Y.”)
• The proposal lists assumptions and risks explicitly.
• The team you’ll work with is in the proposal, by name and role.
• The contract is short and clear, not 40 pages of CYA.
• They invite you to talk to past clients without prompting.
• They deliver discovery output before asking for the build deposit.

How Gsoft answers each of these

We could go through all 12 here, but the short version: we share architecture diagrams, we put the engineers in front of you, we own incident response with documented runbooks, we transfer everything on completion, we test in CI, we use a written change-request process, we hand over with documentation and a KT session, we run security reviews on every fintech build, we deploy through GitHub Actions, IP transfers on payment, we’ll introduce you to references on request, and we say no — fairly often.

The full picture is on our services page. The case studies are in our portfolio. And if you want to test us against this checklist, send us a brief and we’ll show our work.