Custom software built for Nigerian businesses — not a template.

When a business has outgrown its spreadsheets

Almost every custom software project we take on starts in the same place: a spreadsheet that three people edit, a WhatsApp group where decisions are made, and one person who is the only one who knows how it all fits together. It works, until volume doubles, or that person goes on leave, or two versions of the truth appear and nobody can tell which is correct.

The cost of staying there is rarely a single dramatic failure. It is the slow leak — hours lost re-keying data between systems, invoices chased twice, stock counted three times, reporting that takes two days to assemble and is out of date by the time anyone reads it. Most businesses discover the size of that leak only when we sit with their team and time the work.

Off-the-shelf software solves this for standard problems, and when it does we will tell you to buy it rather than build. Custom development earns its cost when your process is genuinely your own — the thing you do differently from competitors, the workflow that is your actual advantage — and bending it to fit someone else's product would mean giving that advantage up.

How we scope, build and hand over

We begin with a paid discovery: a week or two of sitting with the people who will use the system, watching the current process, and writing down what actually happens rather than what the org chart says happens. The output is a scoped specification with screens, data model and a fixed-price build plan. You own that document whether or not you build with us.

Delivery runs in two-week increments against a visible backlog. At the end of each one there is something running that you can open and use — not a status report. That cadence means scope questions surface while they are still cheap, and it gives your team time to absorb the change instead of meeting the whole system on go-live day.

Our default stack is TypeScript end to end — Next.js on the front, Node and PostgreSQL behind it, hosted on infrastructure that scales without a systems administrator. It is deliberately boring and widely known: if you later hire in-house or move to another partner, you are handing over a codebase thousands of Nigerian developers can read, not a bespoke framework only we understand.

What we build most often

Internal operations platforms are the bulk of it: systems that replace the spreadsheet-and-WhatsApp layer with real records, permissions and an audit trail. Job tracking, inventory, scheduling, approvals, field reporting — the unglamorous software that decides whether a growing business keeps its margins.

Customer-facing portals are the second category. Letting clients check status, download documents, make payments and raise requests themselves removes an enormous volume of phone calls and email, and it tends to be the change staff notice first.

The third is integration work: making the systems you already pay for talk to each other. Accounting software, payment gateways, logistics providers, bank statements, an existing ERP. Often the highest-return project is not new software at all but a set of reliable connections between what you already own — and we will say so when that is the case.

Security, data and keeping it running

Access control is designed in from the first sprint, not added when someone notices: role-based permissions, row-level rules so people see only their own records, hashed credentials, and audit logs on every consequential action. For businesses handling health, financial or student data this is not optional, and retrofitting it is considerably more expensive than building it in.

Payment data never touches your servers. Card handling stays with PCI-compliant gateways — Paystack, Flutterwave — and your system stores references, not card numbers. Backups are automated and, more importantly, restoration is tested, because an untested backup is a hope rather than a plan.

Every system ships with error monitoring and uptime alerting wired up, so problems reach us before they reach your customers. Support after launch is a written agreement with a defined response time, not an informal promise — and, as with everything we build, the code and the infrastructure accounts are in your name.

What it costs and how to start small

A focused internal tool — one workflow, a handful of user types — typically lands between six and ten weeks. A platform replacing several disconnected systems is a three-to-six-month programme, usually delivered in phases that each stand on their own. We price per phase, so you can stop, reassess or change direction at a phase boundary without stranding the investment.

If you are not sure the whole thing is justified, start with the single most expensive manual process in the business. Automate that, measure the hours it returns, and let the result decide whether phase two happens. We would far rather build one thing you demonstrably need than a platform that impresses in a demo and gathers dust in production.

Build, buy, or integrate what you already own

Before scoping a build we work through the alternatives with you honestly. Buying beats building whenever your requirement is genuinely standard — accounting, payroll, email, basic CRM. These are solved problems, the products are mature and cheap relative to development, and a custom version would cost more and do less. If that is your situation we will say so and help you choose a product instead.

Integration is the middle path, and it is undervalued. Many businesses already own most of what they need but operate it as islands, with staff acting as the connective tissue between systems. Building the connections — so an order in one place becomes an invoice in another without a human retyping it — often delivers most of the benefit of a new platform at a fraction of the cost and risk.

Building is right when the process is your differentiator, when no product fits without distorting how you work, or when the integrations you need do not exist. Even then, we look for the smallest version that proves the value. A system that does one important thing well and is genuinely used beats a comprehensive platform that staff quietly route around.

What the project needs from your side

The projects that go well share one trait: a decision-maker on your side with the authority to settle questions within a day or two. Not a committee, and not someone who must escalate every choice. Most delays we see are not technical — they are a question sitting unanswered for a fortnight while a sprint's worth of work waits behind it.

We also need access to the people who do the work today, for a few hours at the start and an hour or so per fortnight afterwards. The person who actually processes the orders knows the exceptions that never made it into any documentation, and those exceptions are what break systems designed purely from management's description of the process.

Finally, expect to spend time on testing. Software that has only been checked by the people who built it meets reality on launch day, which is the most expensive place to meet it. We ask for a few hours from two or three of your staff at the end of each phase, working through real cases with real data.