Languages
- Python
- JavaScript
- TypeScript
- SQL
- Go
Open to remote roles
Software EngineerPython DeveloperAI Engineer
Building scalable backend systems and intelligent AI-powered applications.
rag-pipeline · live
since Nov 2019
across 5 companies
languages to vector stores
REST, GraphQL, WebSocket
shipped to production
About
I build the systems that sit behind the product — the APIs, the data pipelines, and increasingly the AI that reasons over them.
Over the past six years I have shipped production software across payments, document intelligence, construction, HR analytics and pharma logistics. My core is Python — FastAPI and Django — paired with Node.js, and lately a lot of applied AI: retrieval-augmented generation, LLM integration and agentic workflows that actually hold up outside a demo.
I care most about the unglamorous parts of engineering. Schema design that will not need a migration in six months. Idempotent webhooks. Retrieval that returns the right chunk instead of a plausible one. Guardrails so a chatbot answers "I do not have that record" rather than inventing it.
I have also led a web team, which taught me that architecture decisions are mostly communication decisions. I am comfortable owning a feature end to end, from the Postgres index up through the Nuxt component that renders it.
Service-oriented FastAPI and Django systems with async task queues, message brokers and clean separation between transport and domain logic.
RAG pipelines with document parsing, chunking and vector retrieval — built so the model stays inside the provided context and refuses to guess.
Postgres window and aggregation functions, duplicate-safe ingestion, and Mongo schemas shaped around real query patterns rather than convenience.
AWS Lambda, S3, DynamoDB and GCP deployments, containerised with Docker and shipped through repeatable CI/CD.

B.E. — Computer Science & Engineering
Rajiv Gandhi Prodyogiki Vishwavidyalaya · Bhopal, MP
2019
Higher Secondary — PCM
Uttar Pradesh Board · Ballia, UP
2013
Stack
Grouped by what they're for rather than by hype. The meters are an honest self-assessment: five blocks means I've run it in production under load, three means I'm productive and still learning the edges.
Selected work
Client and product work from the last six years — document AI, payment rails, approval engines, high-throughput parsers. These are private codebases, so what you get here is an honest account of what I built rather than a repo link.
DEVtrust 2025 — Present
Departmental document management with an AI smart-search layer that answers questions from uploaded PDFs.
DEVtrust 2025 — Present
A RAG chatbot engineered to stay inside its context — it says "no record" instead of inventing one.
Dreamztech Solutions 2021 — 2024
Payment gateway backend covering admin, merchant and user modules with multi-way fund collection.
UniteCloud 2024 — 2025
Construction project management system with dependency-aware milestone tracking. Led the web team.
UniteCloud 2024 — 2025
Full-stack HRMS that analyses employee attrition and predicts leave, reading live from Odoo.
DEVtrust 2025 — Present
High-throughput Go tool that maps messy CSV and PDF data onto relational schemas without duplicating rows.
Experience
From a first web development role automating sales reports to leading a web team and now building production AI systems. Expand any role to see what it actually involved.
Took generative AI from proof of concept into departmental production — semantic search over document archives plus automated drafting of notices, circulars and summaries from file context.
Expertise
Every one of these is a thing I have had to make work under real constraints — private data that cannot leave the estate, documents that resist parsing, and users who will notice immediately when a model makes something up.
parse → chunk → embed → retrieve
The whole pipeline, not just the vector search. Documents are extracted with Docling, chunked so context survives the split, embedded into Qdrant or Chroma, and retrieved with the filters that keep one tenant out of another's data. Retrieval quality is a data problem long before it is a model problem.
drafting from context
Using models to produce real work product — notices, circulars and summaries generated from the contents of a specific file, in the format the department actually files.
tools, not just text
Giving a model typed tools and letting it choose: query the database, call the API, fetch the document. The engineering is in the tool boundary and the failure handling.
multi-step, stateful
Workflows that plan, act, observe and retry across several steps while holding state — graph-based orchestration rather than one prompt hoping to do everything at once.
local or hosted
Serving models locally through Ollama when data cannot leave the estate, or calling hosted APIs when it can — behind one interface so the choice stays reversible.
refuse over invent
A chatbot that answers "I do not have that record" is more valuable than one that guesses. Strict grounding to retrieved context, input and output validation, and scoping so answers cannot cross tenant boundaries.
trace, score, regress
Tracing chains to see which retrieval step actually degraded, scoring answers against a fixed question set, and catching regressions before a prompt change ships.
contracts first
Typed, versioned, documented interfaces — FastAPI with Pydantic models, GraphQL where the client shape justifies it, and idempotent webhook handlers because third parties retry.
split on seams
Service boundaries drawn where the domain actually divides, with message brokers between them so one slow consumer degrades a feature instead of the product.
async by default
Long work moves to Celery, real-time traffic moves to WebSockets over Redis, and the database is asked the right question — window and aggregation functions instead of a loop in Python.
References
Illustrative quotes drawn from the kind of feedback these projects generated — real named references available on request.
Dipu took the approval logic we had been patching for months and turned it into a configuration problem. New request types stopped needing a release.
He was the one insisting the chatbot should say it does not know. That decision is why the department trusted the tool enough to keep using it.
Reliable with a deadline and unusually careful about the database layer. As team lead he reviewed thoroughly without becoming a bottleneck.