Buyer guide

How to choose a software development partner

Choose the partner who asks the hardest questions about your process, shows you how they test and hand over software, and puts ownership of the code in writing. Portfolio and hourly rate matter less than how they handle uncertainty, security and the years after launch.

The short answer

The right software development partner is the one that understands your problem before it proposes a solution, is open about how it builds and tests, and leaves you in control of what you paid for. In practice, that means five things: a real discovery process, a delivery approach you can see working, security built into development rather than bolted on, written ownership of code and accounts, and a clear arrangement for support after launch.

Price and portfolio matter, but they are poor predictors on their own. A low rate spent on the wrong scope is expensive, and an impressive portfolio tells you little about how a firm behaves when requirements change halfway through.

Five things to judge a partner on

1. How they discover and scope

Ask what happens before any code is written. A good partner will want to speak to the people who do the work, see the spreadsheets and systems involved, and understand the exceptions. Be cautious of a fixed quote produced after one call: either the scope is very simple, or the risk is hidden somewhere in the assumptions.

Good signs: they ask about your data, your integrations and who will own the software after launch. They are willing to recommend buying or integrating instead of building, as our build, buy or integrate guide explains.

2. How they deliver

Ask to see how a typical project runs week to week. You want short iterations, working software demonstrated regularly, a visible backlog you can reprioritise, and a named person on their side who is accountable for delivery. Ask how they handle a change request and how it affects cost and schedule.

3. How they build securely

Ask which secure development practices they follow and how they check their own work. Frameworks such as NIST's Secure Software Development Framework and the OWASP Application Security Verification Standard give you a shared language for this conversation. You do not need to be a security expert to ask: how are dependencies kept up to date, how are secrets stored, who reviews code before it ships, and how are access controls tested for each user role?

4. Who owns what

Under Nigerian copyright law, the author of a work (or, in many cases, the author's employer or the person who commissioned it) is generally its first owner, and an assignment of copyright generally needs to be in writing and signed. So if you want to own the code an outside firm writes for you, the contract needs to say so. Ask your lawyer to confirm the position under the current Copyright Act for your situation. Check also:

  • Source code lives in a repository your organisation owns, or is delivered to it regularly, not only at the end.
  • Cloud accounts, domains and app store listings are registered to your organisation.
  • Any reusable components the partner keeps are licensed to you on terms you understand.
  • Third-party and open-source licences used in the software are listed.

This is general information, not legal advice. Have your lawyer review the agreement.

5. What happens after launch

Software needs security updates, monitoring and fixes for as long as it is in use. Ask what support looks like, what it costs, how requests are logged and prioritised, and how response targets are written into the service agreement. Ask what happens if you later want someone else to maintain it: a partner confident in its handover will be comfortable with that question.

Nigerian considerations people forget

  • Data residency and access. If developers or support staff outside Nigeria will be able to access personal data, that is a transfer. Under the Nigeria Data Protection Act 2023 (NDPA), you remain responsible for personal data a partner handles for you, you need a written contract with appropriate safeguards, and the NDPA's rules on transfers outside Nigeria apply. The Nigeria Data Protection Commission publishes the Act and its 2025 implementation directive (GAID). Ask where the team works and where test data lives.
  • Real data in testing. Ask whether they use anonymised or synthetic data in development and test environments.
  • Accessibility, mobile and connectivity. Many of your users will be on phones and on connections that drop. Confirm the partner has built for that before, including offline-tolerant behaviour where it matters, and that they target WCAG 2.2 AA for accessibility as good practice rather than treating it as a later phase.
  • Time zones. A partner whose working day overlaps yours (West Africa Time) makes decisions faster, especially during testing and go-live.
  • Dollar-priced tooling. Cloud hosting, app store fees and licences are often priced in US dollars. Ask which costs in the estimate are exposed to exchange-rate changes.

Rather talk it through? Bring your shortlist questions and we will answer them for your actual project, in writing. Talk to a Promatics specialist

A partner comparison worksheet

Score each firm from 1 to 5 on each line and write down the evidence, not just the number.

CriterionFirm AFirm BFirm CEvidence
Asked about exceptions, data and integrations before quoting
Listed assumptions and exclusions in writing
Showed how iterations, demos and change requests work
Explained secure development and code review practices
Code, accounts and IP assigned to you in writing
Clear handover: documentation, credentials, deployment steps
Support agreement with defined response targets
Answered data protection and data-location questions clearly
  • We spoke to someone who will actually work on the project, not only sales.
  • We saw a sample of their documentation or handover material.
  • Our lawyer reviewed the IP, confidentiality and exit terms.

Red flags worth walking away from

  • A firm quote with no discovery and no written assumptions.
  • Reluctance to put code in your repository until the final payment.
  • "We will handle security" with no detail when you ask how.
  • No clear answer on who supports the software after launch.
  • Pressure to sign quickly, or a discount that expires in days.

Common objections, answered honestly

"A freelancer would be cheaper." Often true for small, well-defined work, and a good freelancer can be an excellent choice. The risk grows with the size and importance of the system: a single person is a single point of failure for holidays, illness and knowledge.

"We could build it ourselves with AI coding tools." For a prototype or an internal utility, that can work. For software that holds customer data, connects to your ERP or must be supported for years, you still need someone to own the design decisions, the testing, the security and the 2 a.m. problem. AI speeds up the typing; it does not take responsibility.

"Switching partners mid-project feels too risky." It is less risky when code, accounts and documentation are already yours. That is exactly why ownership belongs in the first contract.

What working with Promatics looks like

We start with discovery and a written recommendation. If building is right, we agree a first release, deliver it in short iterations with regular demonstrations, test it against your real business rules, and hand over code, documentation and infrastructure in your organisation's accounts. Support after launch sits in a separate agreement with response targets written down. See software development for how we work across web, mobile and custom applications.

When to bring in help

If the software is small, internal and low-risk, a capable freelancer or in-house developer may be the right call. Bring in an experienced partner when the software will hold personal or financial information, connect to systems you depend on, serve customers directly, or need support for years. In those cases, the cost of choosing badly is far higher than the difference between quotes.

Sources and further reading

Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.

  1. Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218), National Institute of Standards and Technology
  2. Application Security Verification Standard, OWASP Foundation
  3. Nigeria Data Protection Act 2023 and GAID 2025, Nigeria Data Protection Commission

This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.

Talk to Promatics

Put us through the same questions you would ask anyone

Choosing a partner for software you will depend on for years is a big decision, and it is hard to judge from a sales deck. Bring your project and your toughest questions, and we will show you exactly how we would scope, build, test and hand it over.

  • A written recommendation, even when the answer is not to build
  • Code, accounts and documentation owned by your organisation
  • Security and testing practices you can inspect, not just trust