MVP development in Nigeria
A first release, not a platform
Founders often ask for the full product on day one. What they need first is a version that can fail cheaply in front of real users. That is the MVP Charis Blueweb Ltd builds from 27 Adebajo Street, Kongi, Bodija, Ibadan: one audience, one job, working sign-in, and a path to collect money or applications. The studio is in Ibadan. The first release is not a city franchise.
We turn an early idea into something people can actually use, with just enough scope to test the market before you over-build. Not a forty-feature wishlist. Not a pitch deck with every competitor’s screen copied into one backlog. If you cannot name the first ten people who will try it, you do not have an MVP brief yet. You have a story. We can help cut the story. We will not pretend the cut is free architecture for an unfunded idea.
How we help
Idea validation first: who pays, what they do in the first session, and what can wait. Then MVP design and a clickable prototype so you can reject a direction before code starts. Then a tight build of the essentials. Then a live URL or app build you can put in front of those ten people. We do not sell “growth tracking” as if a dashboard were the product. You measure whether those people finished the job.
If staff already run the process on paper and money already moves, you are asking for software development. If the job is “explain the firm,” you need web design. If the job is a catalogue and checkout, you need ecommerce. An MVP is for an unproven product. Do not book this page to rename a full platform.
From idea to something people can use
We shape the concept and name the real problem. We check demand with people who can say no, not only colleagues who will be polite. We design the first-user flow and screens. We ship only the features that prove the assumption. We release on real hosting you can open. Then you watch those first users. Each stage ends with a deliverable and a decision: continue, cut, or stop.
That is a loop, not a six-month silence. You should click something every week: a sign-up that now works, a record that now saves, a payment that now completes. If two weeks pass with only slides, the project is drifting. We will stop and ask why. A demo that only the developer can operate is not a demo. We will not quote a launch date before the feature list is cut.
How we cut the first release
Write the first user on one line. Write the first job on one line. Write whether they pay, apply, or only look. Cross out every feature that is not required for that job. Admin screens, extra roles, notifications, referral loops, and a second user type stay out of version one unless they are the product. If the list is still a page long, you are designing a platform. Come back when the list is a paragraph.
You will be asked to drop features you like. That is the work. A first release that tries to please a board, a cousin, and a future enterprise client will not ship. We ask for one decision-maker. Design comes first so you can reject a direction before code starts. Phone +234 802 092 9620. Ibadan clients can walk into Bodija. Others brief on a call.
After the first users
You either learn and stop, or you fund the next slice. Both are respectable. We can stay on for that slice. We do not pad the first release to keep a retainer. If the next slice is a phone client, see app development. If the next slice is a marketing site people can find, see SEO. Pretending the first release was secretly the full product is how teams spend a year polishing a thing nobody finished using.
After launch, admin access and project IP transfer once invoices are cleared, as written in the services agreement. Hosting and third-party accounts stay in your name where possible so you are not locked to a vendor login you cannot see. We can use non-confidential work in the portfolio unless you sign an NDA. If you want an NDA before the brief, say so on the contact form.
What you owe the project
Decisions in the same week we ask. Copy for the empty states. A merchant account if money moves. A willingness to ship something small in public. Name the ten people. If they are imaginary, wait. If they are only colleagues, find ten people who can say no. A founder who cannot attend reviews should not book a first release. A founder who wants a guarantee that users will pay should not book one either.
Send the idea, the first user, and the first job. Do not send a competitor’s entire feature list and call it a specification. We will help you cut it. We will not build the uncut version and call it an MVP because the invoice looks friendlier.
MVP work we will decline
We will decline “the full platform but call it an MVP.” We will decline a first release with no named users. We will decline unpaid equity with no specification. We will decline a launch-date promise before the list is cut. We will take one audience, one job, and a live URL or build that ten people can try. If money already moves and staff already run the process, we will send you to software. If you only need enquiries, we will send you to web design. The cut is the product.
To scope an MVP, use the contact form and name the first user and the first job.
Frequently asked questions
An MVP is the smallest product that takes a real user through the core job: sign up, do the thing, pay or apply. Extra roles, referral loops, and “nice” reports wait.
No. Most briefs start there. We turn a rough idea into a cut feature list before design or code. We will not start a build from a paragraph that still wants the full platform.
Whatever proves the core assumption. If a feature is not required for the first ten users to finish the job, it waits until you have usage to justify it.
You either learn and stop, or you fund the next slice. We can stay on for that slice. We do not pad the first release to keep a retainer.
