Building Search for a Construction Market Where Everyone Calls the Same Product Something Different - Tameer.ai

Talal Siddiqui — Sat, 11 Jul 2026 03:44:41 GMT

The problem nobody warns you about

When I set out to build Tameer.ai — a construction materials and professionals marketplace for Pakistan — I assumed the hard engineering problems would be the usual startup ones: uptime, payments, fraud, scale. They were. But the problem that actually broke our first version of search wasn't infrastructure. It was language.

Ask ten people in Lahore for "sariya" and you'll get steel reinforcement bars. Ask for "rod" and you'll get the same thing. Ask for "rebar" and, if the vendor is English-educated, you'll also get the same thing. Now multiply that across 41 categories and 900+ subcategories of construction materials — tiles, cement, sanitary fittings, electrical fixtures, hardware — each with their own English name, Urdu name, Roman Urdu spelling (which itself isn't standardized), brand-specific naming, and regional dialect variation. A vendor in Karachi and a vendor in Faisalabad might list the exact same product under names that share zero characters.

Keyword search collapses immediately in this environment. If a buyer types "saria" and the listing says "steel bar," a naive LIKE query or inverted index finds nothing. Multiply that mismatch across every category, and you don't have a search problem — you have a trust problem, because buyers assume the product simply isn't available.

Why semantic search, not better keyword matching

Our first instinct was to patch this with synonym dictionaries — manually map "sariya" → "steel bar" → "rebar" → "rod," and so on for every product family. That works until it doesn't: it's a maintenance burden that scales linearly with your catalog, it breaks the moment a vendor uses a phrase you haven't anticipated, and it does nothing for descriptive queries like "waterproof bathroom tile for small space," where there's no fixed synonym to map to at all.

What we needed was search that matched meaning, not strings. That's the case for embedding-based semantic search: instead of indexing listings by their literal text, you encode each listing's title, description, and category into a vector that captures its meaning, and you encode the buyer's query the same way. Matching becomes a nearest-neighbor problem in vector space rather than a string-matching problem in text space. A query for "sariya" and a listing titled "steel reinforcement bar" can end up close together in that space even though they don't share a single token — because the model has learned that they mean the same thing.

The genuinely hard part for a market like ours isn't the architecture — it's the data going into it. Off-the-shelf embedding models are trained overwhelmingly on English (and to a lesser extent, standard Urdu script). Roman Urdu — Urdu written in Latin characters, spelled inconsistently, often mixed mid-sentence with English — is exactly the kind of code-mixed, non-standard text these models handle worst. If you're building for a similarly underrepresented language market, this is the step to budget real time for: evaluating candidate models against your own real listings and real queries, not against benchmark datasets that were never designed to reflect how people in Lahore (or wherever your users are) actually type. A model that looks great on a public leaderboard can still fail quietly the first time it meets code-mixed Roman Urdu.

Image search: when buyers can't describe what they want in any language

A second pattern showed up fast once we had real usage: a lot of buyers, especially homeowners and smaller contractors, don't have the vocabulary to describe what they want at all — in English, Urdu, or Roman Urdu. They have a photo. A tile pattern from a magazine. A fitting they saw installed in a relative's house. "What is this thing called" is often the actual question, not "find me this thing."

That's the case for image-based search: let people upload a photo and match it against the visual features of the catalog rather than requiring them to translate what they're looking at into a search query first. Conceptually, this works the same way semantic text search does — extract a vector representation of the uploaded image, and find catalog items whose image vectors are closest to it — but the practical challenges are different. Vendor-submitted product photos are wildly inconsistent: different lighting, backgrounds, angles, phone cameras. Getting useful matches meant being deliberate about normalizing and filtering vendor images at ingestion time, not just at query time, since a bad reference image degrades every future match against it.

The chatbot and moderation problem are actually the same problem

Two more AI features came out of the same underlying need: an AI chatbot that helps buyers navigate 900+ subcategories without needing to know our taxonomy, and automated content moderation for vendor-submitted listings at scale.

These look unrelated on the surface, but they share a core requirement: understanding unstructured, informal, code-mixed text well enough to classify intent — whether that's "what is this buyer actually trying to procure" or "does this listing contain something it shouldn't." Building one forced us to get disciplined about the other. The moderation pipeline in particular mattered more than I expected going in: with 300+ vendors onboarding self-service, listing quality and spam/fraud control isn't a nice-to-have, it's what determines whether buyers trust the marketplace enough to come back.

What I'd tell another founder building for an underserved language market

If you're building search or discovery for any market where the primary language isn't well-represented in mainstream training data — and that's most of the world outside a handful of languages — the lesson that generalizes isn't a specific model or vector database. It's this: your evaluation set is the actual product. Anyone can wire up an embedding model to a vector index in an afternoon. What takes real work, and what nobody else can do for you, is building a representative set of real queries and real listings from your own users and using that — not a public benchmark — to decide whether your search is actually working.

We built Tameer.ai to be zero-commission for vendors, which meant we never had the luxury of throwing a large team or a large budget at this. Every one of these systems was built to be maintainable by a small technical team, which shaped a lot of the "boring" decisions — favoring approaches we could debug and retrain ourselves over black-box solutions we'd be dependent on. That constraint, more than any clever trick, is probably the most transferable part of this story.