Most software projects that go wrong in Nigeria don’t fail because of the code. They fail because nobody agreed what was being built, the budget ran out halfway, or the software worked in the office and not in the street. A little planning prevents all three.
Here’s a plan you can follow, whether you’re building a customer portal, an internal tool or a whole platform.
1. Start with the problem
Write one paragraph that describes what’s going wrong today, and what would be different if the software worked. For example: “Orders arrive by phone, WhatsApp and email, and some get lost. We want every order in one place, so nothing is missed.”
If you can’t write that paragraph, you’re not ready to talk to developers yet.
2. Decide what success looks like
How will you know the project worked? Pick a few things you can actually check: fewer lost orders, a new staff member using it without help, customers able to track their own deliveries.
3. Write down what the software must do
This is the most valuable step, and the one most often skipped. List who will use the software, what each of them needs to do, the rules your business follows, and what must never go wrong. Our guide on writing a software requirements specification walks through it, and requirements engineering is the service if you’d like help.
4. Set a budget, and a way to spend it in stages
Decide what you can spend in total, then plan to spend it in stages, each ending with something you can use or see. Our guide to what custom software costs explains what moves the price.
5. Choose the right team
Talk to more than one developer, and give each the same written requirements. Ask how they work, who owns the code, how they test and what happens after launch. Here are twelve questions worth asking.
6. Plan how the parts fit
Before building, someone should design how the pieces fit together: the apps, the database, the connections to payments and messages. It’s cheaper to fix a diagram than a finished system. That’s system architecture.
7. Build in small pieces you can see
Ask to see working software every week or two, not a big reveal at the end. Small pieces let you spot misunderstandings early, while they’re cheap to fix.
8. Test where the software will really be used
Your users are probably on Android phones, often mid-range ones, on mobile data that comes and goes. Test there, not just on fast laptops. Our guide to testing on real phones explains how.
9. Launch carefully
Launch when you’re ready, not on a date picked months ago. Have a plan for rolling back if something misbehaves, and someone available on launch day. Start with a small group of users if you can.
10. Look after it
Budget for updates, security patches, monitoring and fixes from the start. Software that nobody looks after slowly breaks. That’s what maintenance and support is for.
A plan on one page
| Stage | What you get |
|---|---|
| The problem | One paragraph everyone agrees on |
| Requirements | A clear, agreed list of what the software must do |
| Budget | A total, and stages to spend it in |
| Team | A developer who answered your questions well |
| Architecture | A plan of the parts and why |
| Build | Working pieces, early and often |
| Test | Results from real phones and real networks |
| Launch | A careful go-live with a way back |
| After launch | A plan, and a budget, to keep it healthy |
This is close to how we work on every project. If you’d like help with any stage, start a conversation.