All projects
CupidFaces Live

NaijaBased

Nigerian business discovery and ordering platform, 2,200+ businesses, zero paid acquisition

2,200+
Businesses listed
Zero
Paid acquisition
15+
Nigerian states
12
Business categories
MarketplaceSEO GrowthFintechMulti-platformNigeria

Overview

NaijaBased is a business discovery and ordering platform for the Nigerian market. Customers use it to find local businesses, browse digital menus via QR code, and place orders (pickup, delivery, in-person, or home visit) and pay via Paystack. Business owners list their businesses, set up menus, manage orders, and withdraw earnings. It covers 15+ Nigerian states across 12 business categories and grew to 2,200+ listed businesses entirely through organic SEO, with no paid acquisition.

The platform has two sides: a consumer-facing discovery and ordering experience, and a vendor portal where business owners manage their operations. Both have gone through two major phases.

V1 was a PHP monolith with eight modules: business listings (the core), jobs, events with Paystack ticket sales, a marketplace for buying and selling items, community groups with their own sub-platforms, professional portfolio pages, a social feed with hashtags and follows, and a referral and points system. The vendor side was a separate portal at shop.naijabased.fun with three distinct dashboards depending on business type: restaurant/food, retail/store, and service. The bonus system rewarded vendors for hitting monthly revenue milestones, with Bronze, Silver, and Gold tiers paying out up to 10,000 NGN for hitting 200,000 NGN in monthly revenue.

V2 is a Next.js 16 rewrite that focused the product on what was actually driving value: business discovery and ordering. The jobs board, events, communities, marketplace, and social feed were removed. The backend remains a PHP REST API, and the vendor portal also moved to Next.js with a unified dashboard replacing the three separate V1 dashboards. The vendor portal in V2 handles order management, menu and product management, customer tracking, scheduling, analytics, wallet, and withdrawals, regardless of business type.

My Role

  • Designed the organic SEO growth strategy: every business profile is its own crawlable page with clean URLs, location-specific metadata, and Schema.org structured data, which drove 2,200+ listings without ad spend
  • Designed the freemium onboarding for business owners: minimum required fields, mobile-optimised form, no payment details required upfront to list
  • Built the monetisation model: free listing for discovery, featured monthly/annual placement, Menu Pro subscription for ad-free ordering pages and QR code menus
  • Designed the vendor bonus programme in V1: revenue-based Bronze/Silver/Gold tiers with monthly milestone payouts
  • Led the V2 scope decision: cut the social and community layers, keep the core discovery and ordering product, rewrite frontend to Next.js
  • Designed the V2 vendor portal as a single unified dashboard covering all business types rather than maintaining three separate codebases
  • Owned the QR menu product: physical businesses generate a QR code linking directly to their branded digital menu with Paystack ordering

Architecture

Consumer site V1 used PHP with session-based auth, vanilla JS, and AJAX handlers. The database is MySQL on Namecheap hosting (falkdnmx_naijabased). Paystack handled payments. Brevo SMTP handled email. Mocean handled SMS. Business profiles had sitemap entries generated for SEO.

Consumer site V2 is Next.js 16 with React 19, TypeScript, and Tailwind CSS 4. The backend is the same PHP REST API at /api/v1. Auth uses JWT tokens stored in an httpOnly cookie (nb_token). ISR handles caching with 60-300 second revalidation per page type. Business profiles use Schema.org LocalBusiness structured data for SEO.

Vendor portal V1 had three separate dashboard codebases for restaurant, retail, and service business types. Each had its own order flow, menu management, and analytics pages. Paystack subaccounts handled per-vendor settlement so vendors received payments directly rather than through a platform wallet.

Vendor portal V2 is also Next.js 16 with React 19, proxying all backend calls to the PHP API at the same database. The unified dashboard handles all business types: orders, bookings (appointments), menu items and categories, customer records, analytics, payment settings, schedule, wallet, and withdrawals.

Key Decisions

Organic search as the only acquisition channel
There was no budget for paid ads, so the product had to earn its own traffic. Every business profile was structured as a standalone, crawlable page with a clean URL (/biz/slug), unique title and description, OpenGraph tags, and Schema.org LocalBusiness markup. That structure is what got the platform to 2,200+ businesses indexed and discoverable without any ad spend.
Cutting eight modules down to one in V2
V1 had jobs, events, marketplace, communities, professional profiles, social feed, hashtags, and referrals on top of the core business directory. Most of those modules had low engagement relative to the engineering cost of maintaining them. The V2 decision was to cut everything except business discovery and ordering, which was where the actual usage was concentrated.
Paystack subaccounts for per-vendor settlement
Rather than collecting all payments into a platform account and then distributing to vendors manually, each vendor gets their own Paystack subaccount. Customer payments route through the subaccount and settle directly into the vendor's bank account, with the platform taking a commission split at the point of transaction. This removed the need for a manual payout operation and reduced the compliance surface on the platform side.
One vendor dashboard for all business types in V2
V1 had three separate vendor dashboards based on business type (restaurant, retail, service). That meant three separate codebases, three separate UIs to maintain, and bugs fixed in one that needed to be replicated in the others. V2 replaced all three with one unified dashboard that adapts its terminology (menu items vs products, orders vs bookings) but shares a single codebase.

Challenges

Getting business owners to complete their listings
Many business owners in the Nigerian market are not tech-forward, and a long registration form is a quick way to lose them. The minimum required fields to go live were kept as short as possible, the form was optimised for mobile, and payment details were not collected upfront. The Menu Pro upgrade and featured placement were introduced after the owner had already seen traffic coming from the platform, so the upgrade decision felt justified rather than speculative.
V1 had too many modules to evolve the core product
With eight separate modules on one codebase, any change to shared infrastructure (auth, notifications, payments) had to be tested against all eight. Feature work on the business directory was consistently de-prioritised because changes to the social feed or marketplace kept creating regressions. The V2 scope cut was the correct call but it required deprecating features that some users had built habits around.
Maintaining three vendor dashboards in V1
The restaurant, retail, and service dashboards in V1 were separate PHP directories with shared includes but distinct page logic. Fixing a bug in order messaging in the restaurant dashboard meant tracking down the equivalent code in the other two. Adding a new feature meant implementing it three times. V2 unified these into one codebase as a priority.

Stack & Integrations

Next.js 16 + React 19 (V2)PHP REST API backendMySQLPaystack + SubaccountsBrevo SMTPMocean SMSISR CachingSchema.org SEOQR Code Generation