The problem
Buying anything specific in Kenya — a particular sofa, a particular tile, a particular dress — means physically going from shop to shop. Online listings are scattered across Facebook groups, WhatsApp catalogues, and a handful of vertical marketplaces that don’t talk to each other. Search, when it exists, is keyword-only. A shopper who knows what they want but not what it’s called has no way to find it.
We built Finder Africa to be that search layer — a single index across vendor catalogues, queryable by text or by photo.
What we built
Two React Native apps and a single backend.
The shopper app (Finder Client) is a feed-first product discovery interface — search, browse, save, message a vendor. The vendor app (Finder Business) is a catalogue-management surface — upload products, manage inventory, see view counts and shopper enquiries, get paid.
Behind them, a FastAPI service backed by MongoDB for the operational data and Weaviate for the search indices. We run two retrieval pipelines side by side:
- Hybrid text search: BM25 + vector retrieval through Weaviate’s
text2vec-googlemodule, reranked client-side. Catches both literal keyword matches ("3-seater sofa") and semantic ones ("comfy living room couch"). - Visual search: Multi-modal embeddings via Weaviate’s
multi2vec-googlemodule against Vertex AI. A shopper takes a photo of something they like; we return the nearest vendor products in the index.
Identity is Clerk across both apps. Media is Cloudinary with SHA-256 signed uploads. Email is Resend. Everything runs on Google Cloud — the backend on Cloud Run, Weaviate on GKE Autopilot with the sysctlInitContainer disabled (a permanent Autopilot constraint that catches everyone the first time).
Architecture decisions worth flagging
Mongo, not Postgres. Vendor catalogues are deeply nested — variants, options, media galleries, region-specific availability. We needed schema flexibility while vendor onboarding was still moving. With volume, a few collections will migrate to Postgres; the search indices stay in Weaviate either way.
Weaviate, not pgvector. When we started the visual-search path, multi-modal embeddings at this scale through pgvector weren’t a clean fit. Weaviate’s module system lets us swap the embedding provider without rewriting the schema, which we’ve used twice already.
Two separate React Native apps, not one with role switching. A shopper and a vendor want fundamentally different first screens. Roles inside a single binary forced an unnecessary layer of conditionals and lengthened the time-to-first-action on launch.
Module-level token getter, not React context for auth headers. Axios interceptors live outside React’s render lifecycle, so a tokenGetterRef set once at boot is faster and less buggy than threading a Clerk hook through a request layer.
What it’s doing today
Live on the Google Play Store as two separate apps: Finder Client (shoppers) and Finder Business (vendors). Piloting with the Fashion and Home & Decor departments. vendors onboarded; products indexed; .
What we learned
Hybrid search beats either approach alone for Kenyan product names — which mix English, Swahili, brand names, and vendor-specific spellings ("M-Block tiles", "Vitafoam mattress", "kombo"). BM25 catches the brand and SKU language; vector retrieval catches the descriptive shopper language. Reranking with the user’s own clicks tightens it further.
Visual search is the feature shoppers show their friends. It’s also the feature vendors discover their competition through.
Finder Africa is built and operated by CoreLabz. The same patterns — Weaviate-backed search, React Native + FastAPI, Clerk for identity — show up in client engagements where retrieval matters.