I build semantic search systems — embeddings, hybrid retrieval that combines vector and keyword search, reranking, and the relevance evaluation that proves it works — with engagements typically running $15K–$90K depending on corpus size, freshness needs, and permission complexity. I bring 7+ years of production delivery, worked as a Guest Engineer at Expensify, and I'm Top Rated on Upwork with $100K+ earned and verified client reviews. Most engagements go from data audit to a measured, production search system in five to ten weeks, with a golden query set and relevance metrics included so 'better search' is a number, not an opinion.
Users have stopped forgiving bad search — they type what they mean and expect the system to understand it, not match keywords. The hard truth of this service is that embeddings are the easy 20%: what makes semantic search actually work in production is chunking strategy, hybrid retrieval, permission filtering, and a relevance evaluation loop, and that's precisely the 80% most builds skip.
Weekly demos, async Slack updates, production standards.
04
Ship
Store launch, documentation, knowledge transfer.
Engagements this covers
Search that understands your product's content
A knowledge platform, marketplace, or documentation product has keyword search that fails whenever users phrase things differently than authors did. I build hybrid retrieval — embeddings for meaning, keyword scoring for exact matches like SKUs and error codes — with reranking on top, measured against a golden set of real user queries. Outcome: measured relevance gains on the exact queries that used to fail.
Retrieval layer for a RAG application
A team's LLM assistant gives wrong answers because retrieval feeds it wrong context — the model gets blamed for what the search layer broke. I rebuild the retrieval pipeline: document-aware chunking, hybrid search, metadata filtering, and retrieval evals separate from generation evals, so you can finally see which layer is failing. Outcome: answer quality improves because context quality did.
Internal search across scattered company knowledge
A company's knowledge lives across wikis, tickets, drives, and chat exports, and employees ask each other questions the documents already answer. I build ingestion with permission-aware indexing — people find only what they're allowed to see — and a single search surface over all of it, with freshness syncing so results reflect current documents. Outcome: institutional knowledge becomes findable without a reorg.
What the engagement looks like week by week
Week one is a data and query audit: what the corpus actually contains, how documents are structured, and — most importantly — a golden set of 50–150 real queries paired with the results that should come back. That golden set turns every subsequent decision into a measurement, and building it first is the single strongest predictor of a search project succeeding.
Weeks two and three build the pipeline: document-aware chunking (respecting structure — sections, tables, headings — rather than slicing blindly at fixed sizes), embedding generation, and indexing with the metadata needed for filtering. Weeks four and five make it hybrid: keyword scoring fused with vector results, then a reranking stage, each addition scored against the golden set to prove it earns its latency. The remaining weeks are production work — freshness syncing as documents change, permission filtering, latency tuning, and a relevance dashboard so quality stays visible after handoff.
What drives cost inside $15K–$90K
Corpus messiness is the biggest driver — bigger than corpus size. A hundred thousand clean, structured documents are easier than five thousand scanned PDFs with tables, mixed languages, and no consistent structure; extraction and chunking for ugly corpora can be half the project. Freshness is second: a static corpus indexed once is cheap, while continuous sync from live systems — with deletes and permission changes propagating correctly — adds real engineering.
Permission-aware search is the third lever, and the most underestimated: filtering results by what each user may see, efficiently at query time and correctly as permissions change, can double the backend work, which is why I ask about it in the first call rather than discovering it in week six. Query volume and latency targets set the infrastructure tier. A single-tenant search over a stable corpus lands near the bottom of the range; permissioned, continuously-synced, high-volume search lands at the top.
Mistakes teams make buying search
The most common one is vector-only faith: throwing everything into a vector database and assuming embeddings solve search. Pure vector retrieval reliably fails on the queries your users care most about — exact product names, error codes, people, IDs — because embeddings blur precisely what those queries need sharp. Production search is hybrid, nearly without exception, and any vendor who doesn't say so early is reciting a tutorial.
Second mistake: no golden query set, which means relevance is judged by whoever ran the last demo query and every change is a coin flip. Third: chunking as an afterthought — fixed 500-token slices through tables and section boundaries poison retrieval quality in ways no downstream model can repair, and in RAG systems this single decision often matters more than the choice of LLM. Fourth: skipping the permissions conversation until late, then discovering the architecture can't support it — the most expensive possible time to learn that requirement.
How to evaluate a semantic search vendor
Ask how they'll measure relevance — the only good answer involves a golden query set built from your real queries, with metrics like recall and reciprocal rank tracked across every change. Ask when they'd use keyword search over embeddings; anyone who has shipped search will immediately talk about exact-match queries, hybrid fusion, and reranking, while anyone who says embeddings replace keyword search hasn't watched real users type SKUs into a search box. Ask about their chunking approach for your specific document types — the answer should involve looking at your documents first, not a universal token count.
Then ask what happens when a document is deleted or its permissions change — index consistency and permission propagation are where search systems quietly become liabilities, and vendors who haven't operated one won't have an answer. Finally, ask for the latency budget breakdown: retrieval, rerank, and filtering each cost milliseconds, and a vendor who can't itemize them is guessing.
When you don't need semantic search
If your users search for exact things — order numbers, usernames, part codes — well-tuned keyword search with good filters beats semantic search outright, and Postgres full-text search is likely already sitting in your stack, free. If your corpus is small and stable — a few hundred documents — and your users are internal and forgiving, modern LLMs with large context windows can sometimes skip retrieval entirely for simple cases.
Semantic search earns its budget when vocabulary mismatch is the actual failure mode — users phrase things differently than documents do — when the corpus is too large to stuff into context, or when it's feeding a RAG system where retrieval quality caps answer quality. A cheap diagnostic I'll run in a first conversation: pull your top fifty failed queries and look at why they failed. If they failed on synonyms and phrasing, semantic search fixes it. If they failed on filters, typos, or missing content, it won't — and you just saved the budget.
Low-risk to start
✓Fixed-scope proposal first
You approve milestones and a price before any build starts — no open-ended hourly surprises.
✓Working demos every week
You see running software each week, not status reports, so you can course-correct early.
✓One senior owner, no hand-offs
The person who scopes the work is the person who builds it — no junior layers, no agency markup.
✓A track record you can verify
Top Rated on Upwork with public client reviews and $100K+ earned, plus contributions to Expensify. Check the receipts before you commit.
Production semantic search typically runs $15K–$90K. A single-tenant system over a clean, stable corpus with hybrid retrieval and relevance evals lands at $15K–$30K. Messy corpora (scanned PDFs, inconsistent structure), continuous freshness syncing, and especially permission-aware results push into the middle and top of the range. Ongoing costs — embedding generation and index hosting — are usually modest, in the hundreds per month for most corpora.
How long does semantic search take to build?
Five to ten weeks for most systems. Week one produces the data audit and a golden query set from real user queries — the measurement foundation. A working hybrid retrieval pipeline exists by week three or four, with reranking and measured relevance gains following. The remaining time covers freshness syncing, permission filtering, latency tuning, and a relevance dashboard. Systems needing continuous sync from multiple live sources land at the longer end.
Should I use a vector database or Postgres with pgvector?
For most products, start with pgvector: your data likely already lives in Postgres, you keep transactions and joins with your metadata and permissions, and it comfortably handles millions of vectors — while making hybrid vector-plus-keyword queries easy in one engine. Dedicated vector databases earn their operational overhead at much larger scale or specialized filtering loads. The retrieval quality decisions — chunking, hybrid fusion, reranking — matter far more than this infrastructure choice.
How much does semantic search development typically cost?
Projects typically fall in the $15K–$90K range depending on scope, integrations, and timeline. I provide a fixed-scope proposal after a 30-minute scoping call.
How long does a semantic search development project take?
MVPs often ship in 8–12 weeks. Production systems with AI backends or RAG may run 12–20 weeks. Rescue and audit engagements can start within days.
Do you work with startups and enterprises?
Yes. I work with founders, CTOs, product teams, and agencies worldwide — US, UK, EU, and APAC time zones with async updates and weekly demos.
Can you own mobile and backend together?
Yes. I specialize in React Native + Python (FastAPI) + AI (RAG, agents, OpenAI/Claude) under one senior owner — fewer handoffs, faster shipping.
How do I get started?
Book a free 30-minute scoping call on this site, hire through Upwork, or email dhairyasenjaliya@gmail.com with your brief and timeline.