How to Build a Mobile App With AI Recommendations: From Simple Rules to Machine Learning for Nigerian Apps
What AI recommendations in an app are, and what they are not
AI recommendations are suggestions of items (products, dishes, properties, jobs, lessons, videos, services) chosen for a specific user or context by a system that learns from behaviour and item attributes. The word "AI" covers a range from a popularity list filtered by the user's city to a neural model trained on millions of interactions. They are not a search engine (search answers a stated need; recommendations anticipate an unstated one), not a chatbot, and not a substitute for a good catalogue. A recommendation system can only surface items that are well described, in stock and priced correctly. It also cannot fix an app with too few users to learn from, which is why the first rungs of the ladder are deliberately simple.
The recommendation ladder: five approaches
The difference between the approaches is what information they use and how much data they need. Most apps climb the ladder over time rather than starting at the top.
| Rung | Approach | How it works | Data needed | Typical use |
|---|---|---|---|---|
| 1 | Popularity and rules | Best sellers, trending, "new in your area", manual merchandising | Order counts, item attributes, user location | Launch; cold start; empty states |
| 2 | Content-based | Recommends items similar in attributes to what the user viewed or bought | Good item metadata (category, price, tags, description) | Small user base, rich catalogue |
| 3 | Collaborative filtering | "Users who liked this also liked"; learns from interaction patterns across users | Thousands of users with repeated interactions | Established apps with steady activity |
| 4 | Embeddings and vector similarity | Items and users represented as vectors from text, images and behaviour; nearest neighbours recommended | Item text and images plus interactions; a vector index | Diverse catalogues; semantic "more like this" |
| 5 | Hybrid and LLM-assisted | Combines the above; language models explain, re-rank or build recommendations from natural-language preferences | Everything above plus model API usage | Mature apps; conversational discovery |
A well-built rung 1 with sensible rules (in stock, deliverable to the user's area, within a price band) often outperforms a badly-fed rung 3 model, especially in the first year.
Which approach fits your app and data?
Choose the starting rung from three numbers: how many items you have, how many active users, and how many interactions per user per month.
- Under a few hundred items, under a few thousand users: rungs 1 and 2. Invest in item metadata and rules; collaborative filtering will not have enough signal.
- Thousands of items, tens of thousands of active users, repeat interactions: rung 3, with rung 2 as fallback for new items and new users.
- Large, diverse catalogues with text and images (property, jobs, content): rung 4 becomes valuable because attributes are messy and semantic similarity helps.
- Any size, with an ambition for conversational discovery ("find me a two-bedroom near Gwarinpa under a set budget"): rung 5, built on top of a working rung 2 or 3, never instead of it.
A second factor is how quickly preferences change. Food and fashion shift weekly; property and jobs are one-off decisions where content-based similarity matters more than history.
The data you need before any model
The first step is to record events. Without them there is nothing to learn from, and retrofitting tracking later loses months. Every app that wants recommendations should log the following with a user ID (or anonymous device ID before login), item ID, timestamp and context (screen, position, session):
- Item viewed, and for how long
- Search performed, and which result was tapped
- Item added to cart, saved, shortlisted or shared
- Purchase, booking or application completed, with amount
- Recommendation shown (impression), and whether it was tapped or ignored
- Item skipped or dismissed
- Location or delivery area, device type, time of day
Store events in an analytics or event store that you own (a warehouse table, not only a third-party analytics dashboard), because models need raw rows. Also keep item metadata clean: consistent categories, correct prices, availability by area, and good descriptions and images. Data quality here decides everything above it.
Architecture: computing and serving recommendations
Recommendations are computed in one of two ways and served through your backend so the app stays simple.
- Batch computation. A scheduled job (nightly or hourly) computes recommendations for each user and each item and stores them in a fast table or cache. The app requests "recommendations for user X on the home screen" and the backend returns the precomputed list, filtered for stock, area and price. Cheap, robust, and sufficient for most apps.
- Real-time computation. The backend computes or re-ranks suggestions at request time using the current session (what the user just viewed). Needed for "because you just looked at" and for fast-changing catalogues; more expensive.
Most apps use batch for the heavy lifting and a light real-time layer for session context. Two more components matter:
- Filtering and business rules applied at serving time: exclude out-of-stock, undeliverable or already-purchased items; enforce diversity; boost promoted items transparently.
- Fallbacks: when a user is new or a model fails, serve popularity lists so no screen is ever empty.
Managed services exist (cloud recommendation APIs and vector databases) and can shorten the build, but they bill in US dollars and still need your event data and rules.
Where to show recommendations in the app
Placement is where recommendations either earn revenue or become decoration. Match the placement to the decision the user is making.
| Placement | Purpose | Approach |
|---|---|---|
| Home screen rails ("Popular near you", "Picked for you") | Discovery on open | Popularity by area for new users; personalised for returning |
| Item page ("Similar", "Frequently bought together") | Comparison and add-on | Content-based and co-purchase |
| Cart or checkout ("Add before you pay") | Basket size | Co-purchase, price-capped, one or two items only |
| Search with no or few results | Recovery | Content-based nearest matches |
| Empty states (no orders yet, no saved items) | First action | Popularity and onboarding preferences |
| Notifications ("Back in stock", "New listings like the one you saved") | Re-engagement | Event-triggered, strictly opt-in and capped |
| Post-purchase ("Others also ordered") | Repeat purchase | Co-purchase, timed to the natural reorder cycle |
Every placement should record impressions and taps as events so you can measure it separately.
Step-by-step: building recommendations into the app
- Decide the business goal: bigger baskets, more repeat orders, faster first purchase, or better engagement. One goal per placement.
- Instrument the app with the event list above and confirm the data lands in a store you control.
- Clean the catalogue: categories, prices, availability by area, descriptions and images.
- Ship rung 1 (popularity, trending, rules) with the serving layer, filters and fallbacks, and the impression and tap tracking.
- Add rung 2 content-based similarity for item pages and search recovery.
- Run the first A/B test comparing a placement with recommendations to the same placement without, and keep the winner.
- When data allows, add rung 3 collaborative filtering as a nightly batch job, with rung 2 as fallback for new items and users.
- Consider rung 4 if your catalogue is diverse and text-heavy, using embeddings and a vector index.
- Add session-aware re-ranking for "because you just viewed" once batch recommendations are performing.
- Operate: monitor freshness, coverage (how many items ever get recommended), and business metrics monthly; retrain and retune on a schedule.
Measuring whether recommendations work
The difference between a recommendation feature and a recommendation system is measurement. Track three layers:
- Engagement: impressions, tap-through rate per placement, and share of sessions with a recommendation tap.
- Conversion: purchases, bookings or applications that started from a recommendation, and basket size with versus without.
- Business outcome: revenue per user, repeat rate, and time to first purchase, compared through A/B tests where a random group sees the new recommendations and another sees the old placement.
Run tests long enough to cover a full weekly cycle and, in Nigeria, ideally a month-end. Beware of vanity: a rail with a high tap rate that cannibalises purchases users would have made anyway adds nothing. Compare total outcomes, not just taps.
What changes for Nigerian businesses
Recommendation systems are usually explained with examples from markets with vast data. Nigerian apps face different conditions.
- Small and sparse data. Most apps have far fewer users and interactions than the textbook assumes. Rungs 1 and 2 will carry you further than you expect; jumping to collaborative filtering early produces random-looking results and lost trust.
- Seasonality is strong and specific. December festivities, Ramadan and Eid, Easter, back-to-school and salary cycles change demand sharply. Popularity windows should be short (days, not months) and rules should be able to boost seasonal categories.
- Location and delivery reality. A recommendation for an item that cannot be delivered to the user's area, or a restaurant that is closed, is worse than none. Filter by serviceable area and current availability before ranking.
- Price sensitivity. Recommend within or slightly below the user's observed price band; aspirational "you might also like" items priced far above the last purchase perform poorly.
- Data cost and screen space. Image-heavy rails on mobile data are expensive for users; keep rails short, compress images, and load below-the-fold rails lazily.
- Cold start is the normal state. Many users install, browse once and return weeks later. Onboarding preferences (choose your area, favourite categories) and popularity-by-area do more for these users than any model.
- Privacy. Behavioural profiling uses personal data under the Nigeria Data Protection Act 2023. Disclose it, offer a way to reset or opt out of personalisation, avoid sensitive inferences, and confirm obligations with the Nigeria Data Protection Commission.
Example (hypothetical): a Port Harcourt food delivery app
Example (hypothetical): a food delivery app operating in Port Harcourt has a few hundred restaurants, several thousand monthly active customers and strong lunchtime peaks from office areas. The brief asked for "AI recommendations like the big apps". The team instead climbs the ladder:
- Rung 1 at launch: home screen rails for "Popular near you" (orders in the last seven days within the user's delivery zone, open restaurants only) and "Fast delivery now" (based on live preparation and rider times); an onboarding step asking for area and three favourite cuisines.
- Rung 2 after two months: "Similar dishes" on each item page using cuisine, price band and tags; "Try instead" when a favourite restaurant is closed.
- Measurement: an A/B test on the home rail shows more first orders from new users in the personalised group; a cart "add a drink" placement lifts basket size modestly and is kept; a "you might also like" rail on the checkout screen slows checkout and is removed.
- Rung 3 after six months: nightly collaborative filtering for returning customers, restricted to their zone and lunchtime or dinner context, with rung 2 as fallback.
- Seasonal rules: a manual boost for festive menus in December and iftar bundles during Ramadan.
The design point is that most of the value came from availability filtering, area-aware popularity and honest measurement, with the model arriving only when the data could support it.
How much do AI recommendations cost?
Costs depend on the rung and on whether event tracking already exists. The figures below are indicative 2026 ranges; actual quotes vary with scope, vendor and exchange rate. Compare two or three written quotations on identical scope and ask vendors to state which rung they are proposing and what data they assume.
| Scope | Includes | Indicative one-off cost (₦) |
|---|---|---|
| Event tracking and data store | Event schema, app instrumentation, storage, basic dashboards | ₦300,000–₦1,200,000 |
| Rung 1–2: rules, popularity and content-based | Serving layer, filters, fallbacks, placements, impression tracking | ₦600,000–₦2,500,000 |
| Rung 3–4: collaborative filtering and embeddings | Batch pipeline, model training, vector index, evaluation, retraining schedule | ₦2,000,000–₦8,000,000 |
| Rung 5: hybrid and LLM-assisted discovery | Re-ranking, natural-language preferences, explanations | ₦3,000,000–₦10,000,000+ |
These sit within the general indicative band for AI integration into existing software in Nigeria (₦1,000,000–₦10,000,000+). Recurring costs: data storage and compute for batch jobs, any managed recommendation or vector service billed in US dollars, model API usage for rung 5, and maintenance at roughly 15–25% of build cost per year, which for recommendations includes retraining and rule upkeep.
Mistakes to avoid
- Starting with a model instead of data. No events, no learning; instrument first.
- Recommending unavailable items. Out of stock, closed, or outside the delivery zone destroys trust faster than no recommendation at all.
- Skipping fallbacks. New users and model failures must still see something sensible.
- Measuring taps instead of outcomes. A rail can be popular and worthless; test against revenue and repeat rate.
- Long popularity windows in a seasonal market. Last quarter's best sellers are not this week's.
- Hidden paid placement. Boosted items disguised as recommendations erode trust; label sponsored slots.
- Ignoring cold start. Onboarding preferences and area-based popularity are cheap and effective.
- Buying a dollar-priced managed service before proving value with rules. Prove rung 1 and 2 first.
- Profiling without disclosure. Personalisation is personal data processing; say so and offer a reset.
Conclusion
AI recommendations in a mobile app are built from the bottom up: record events, clean the catalogue, ship rules and popularity with strict availability filtering, add content-based similarity, measure with A/B tests, and only then move to collaborative filtering and embedding models when the data can support them. In Nigeria, where user bases are smaller, seasonality is sharp and delivery reality constrains what can be offered, the simple rungs done carefully outperform ambitious models done early. Treat placement and measurement as the product, and the algorithm as an upgrade path. If you are planning an app that should learn what customers want, or want to add personalisation to an existing one without over-investing before the data exists, Linestech builds data-driven mobile apps and AI integrations for Nigerian businesses and can help you choose the right starting rung.
Frequently asked questions
How much data do we need before machine learning recommendations make sense?
As a rough guide, collaborative filtering needs thousands of active users with repeated interactions across a catalogue of hundreds or more items; below that, patterns are too sparse. Content-based and popularity approaches work from day one because they rely on item attributes and counts rather than cross-user patterns.
Can we use a cloud recommendation service instead of building our own?
Yes. Cloud providers offer managed recommendation APIs and vector databases that shorten the build. They still require your event data, clean catalogue, filtering rules and measurement, and they bill in US dollars, so prove value with rules first and model the cost against your user growth and the exchange rate.
Do recommendations work for a small catalogue?
Yes, in a limited way. With a few hundred items, well-designed rules (popular in your area, similar by category and price, add-ons at checkout) deliver most of the benefit. Sophisticated models add little until the catalogue and user base grow, so spend on metadata and placement rather than algorithms.
Where should recommendations appear first?
On the item page ("similar" and "frequently bought together") and in empty or no-result states, because these are moments where the user is deciding and has few alternatives. Home-screen personalisation matters once users return regularly. Checkout upsells should be limited to one or two capped-price items.
Will personalisation upset customers?
Rarely, if it is useful, transparent and controllable. Explain why an item is shown ("because you ordered from this restaurant"), avoid sensitive inferences, label sponsored slots, and provide a way to reset personalisation. Disclosure is also expected under Nigeria's data protection rules.
How often should recommendations be updated?
Popularity windows should refresh at least daily, and hourly for time-sensitive apps like food delivery. Personalised batch recommendations are typically recomputed nightly. Session-aware suggestions update in real time. Models themselves are retrained weekly to monthly depending on how fast behaviour shifts.
Sources and further reading
Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.
