Retrieval & RAG engineering
Hybrid dense and lexical retrieval, reciprocal-rank fusion, reranking, and chunking strategies chosen against measured recall — not defaults.
Founder
Founder & Lead Engineer, CraftWyre
I build AI systems that cite their sources, refuse to guess, and hold up when the answer matters.
Introduction
I am a software engineer working on applied AI — retrieval systems, multi-agent pipelines, and the product engineering around them. CraftWyre is the company I founded to do that work properly: architecture first, evaluation before claims, and systems a team can still maintain a year later.
Most of my work sits in one narrow place: getting a language model to answer from a specific body of evidence, and to say nothing when the evidence is not there. That constraint shapes everything downstream — how documents are parsed and indexed, how retrieval is scored, how an answer is verified before a user ever sees it, and how the system reports what it could not resolve.
It is a constraint worth taking seriously because of where these systems get used. Legal research, financial analysis, tax and compliance, public-sector information — the domains I keep building for are the ones where a confident wrong answer costs more than no answer at all. Groundline, the product I am developing at CraftWyre, is built entirely around that idea: every answer carries the document, the page, and the excerpt behind it, an independent verification step removes anything the sources do not support, and the system refuses rather than fabricates.
The second thread running through the work is language. Ask in Urdu, get an answer in Urdu — with Arabic, Hindi, Turkish, and right-to-left rendering treated as first-class rather than an afterthought. Most polished tools in this space are English-first. Building for the region I work in meant solving cross-language retrieval properly, and that turned out to be an advantage rather than a tax.
I work across the whole stack because these systems fail at the seams. That means FastAPI and Python for the retrieval and agent layer, Next.js and React for the interfaces, Postgres, Redis, and vector search underneath, Docker and CI around it, and a real evaluation suite so a change to a prompt or a reranker is measured rather than guessed at.
At a glance
- Role
- Founder & Lead Engineer, CraftWyre
- Focus
- Retrieval-grounded AI, document intelligence, agent systems
- Building
- Groundline
- Projects
- 2 shipped or in active development
- Based
- Pakistan · Working with teams worldwide
What I do
These are the layers I build and maintain end to end — from how a document is parsed to how an answer is proven before anyone reads it.
Multi-agent systems
Planner, retriever, synthesizer, and verifier as separate roles with narrow permissions, so document content is treated as data and never as instructions.
Grounding & verification
An independent pass that re-checks every claim and citation against the retrieved evidence and drops whatever the sources do not support.
Multilingual NLP
Cross-language retrieval, Unicode-aware lexical search, language-matched answers, and correct right-to-left rendering across 100+ languages.
Document intelligence
PDF structure extraction with headings, tables, and OCR fallback; page preservation, deduplication, and document versioning through ingestion.
Secure multi-tenant architecture
Server-controlled tenant scope, isolated vector namespaces, envelope-encrypted object storage, scoped RBAC, and structured audit events.
Evaluation & reliability
Regression benchmarks for numeric recall, citation precision, unsupported-claim rate, latency, and cost, wired into CI as release gates.
Full-stack product engineering
FastAPI and Next.js applications with durable background jobs, admin controls, and the operational surface a real deployment needs.
Portfolio
Commercial products, client work, and the systems that came before them. Each entry carries an honest status — nothing here claims a result that has not been measured.
How I work
They cost time up front and save it everywhere else — most of all when a system reaches the point where somebody makes a decision on what it said.
Start with the failure, not the feature
The first question on any system is what a wrong answer costs. That answer decides the architecture — how much verification, how much human review, how much the system is allowed to say on its own.
Evidence over eloquence
An answer that reads well and cannot be traced is worse than a short one that can. Citations, page numbers, and excerpts are product features, not debug output.
Measure before claiming
Retrieval quality, citation precision, unsupported-claim rate, latency, and cost get benchmarked in CI. If a number is not measured, it does not go in a sentence.
Refusal is a feature
A system that knows the boundary of its evidence is more useful than one that always produces something. Saying "not in these documents" is the behaviour I optimise for.
Build it so someone else can keep it
Clear module boundaries, real test suites, written architecture decisions, and deployment that is documented rather than remembered.
Toolkit
Languages
- Python
- TypeScript
- SQL
AI & retrieval
- LangGraph
- LangChain
- Pinecone
- FAISS
- ChromaDB
- BGE-M3
- Rerankers
- MCP
Backend
- FastAPI
- Pydantic
- PostgreSQL
- Redis
- RQ
- Prisma
Frontend
- Next.js
- React
- Tailwind CSS
- Framer Motion
Platform
- Docker
- GitHub Actions
- Prometheus
- S3 + KMS
- Vercel
Have something difficult to build?
Tell me about the users, the information, and what a wrong answer would cost. I will tell you honestly whether this is the right approach and what it would take.