Reldava Tech
I build systems that can prove they work.
Production systems - a multi-tenant RAG platform, an AI chatbot SaaS, a repository analysis engine - designed, built, deployed and measured end to end by one engineer.
Available for contract work.
What I build
Four things, and they tend to arrive together.
RAG, agents and LLM systems
Hybrid retrieval and rerankers; agent loops with their own tools and any MCP server you add; evaluation runs that price a change before it ships; cost and tokens accounted for per request. Models that run inside the deployment as well as behind an API - embeddings normalised to one dimension across providers, a cross-encoder reranking on CPU, local models through Ollama, language detected at ingest so each document is indexed in its own. Pipelines that are versioned and measured, so changing one is an experiment rather than a gamble.
Whole products, not prototypes
Auth, organizations, quotas, billing, an admin console, OAuth integrations, messaging channels, deployment. Everything a demo skips and a paying customer notices on day two - plan limits that indexing counts against as well as chat, an audit row behind every sensitive action, and migrations that carry the whole thing forward without a maintenance window.
Operations you can see
Metrics, traces, prompt-level cost, dashboards provisioned from the repository, runbooks for the incident at 3am. Four tools answering four different questions: what the model saw and what it cost, where the time went inside one request, what is happening across all of them, and when somebody should be woken up. If nobody can tell that it broke, it is not finished.
Codebase analysis
What a repository says about the process that produced it: where rework concentrates, who actually owns which area, what a handover would cost. On a real codebase the developer with the most commits owned three per cent of the backend - the naive count inverts the picture. Evidence, phrased as questions rather than verdicts.
Selected work
A few of the systems I have built. Each one went from an empty directory to a running deployment.
RAG Platform
Documents in, grounded answers out - and the numbers to say whether the retrieval is any good.
A multi-tenant RAG platform where the retrieval pipeline is a graph you edit, version and A/B test on live traffic - and every argument about it is settled by a measured run rather than by taste.
- Hybrid retrieval, per-language indexing, CPU cross-encoder rerank
- Pipelines as versioned data, edited on a canvas
- Seven-metric evaluation runs against the real executor
- Open source under MIT, ADRs included
ReldavaBot
AI chatbots over your own data, built by people who do not write code.
A SaaS that turns a folder of documents or a website into a chatbot you can embed or connect to a messenger - with the retrieval quality of a platform built for engineers and an interface built for people who are not.
- Hybrid search, rerank and query preprocessing, per bot
- Embeddable widget, share links, Telegram, WhatsApp, Messenger, Instagram
- Stripe billing, quotas, admin console, OAuth file sources
PulseRepo
What a repository says about the process that produced it.
A repo-only analysis engine for the people who pay for software but do not read it daily: where rework concentrates, who actually owns which area, what a handover would cost - as questions with evidence, never as verdicts about people.
- Deterministic core: ownership, rework, churn, bus factor
- Function-level analysis with tree-sitter, AI layers on top
- Ranked feed of questions worth asking, each with its evidence
How I can help
Four ways to work together. Each one is scoped in writing before it starts.
Build it
A system taken from an empty directory to production and kept running afterwards: architecture, implementation, deployment, and the dashboard that says whether it is healthy.
Fixed scope, delivered milestone by milestone
RAG and LLM review
An existing AI feature measured rather than argued about: retrieval quality on your own corpus, cost per answer, what a golden set says about it, and the changes worth making first.
One to two weeks, written report with the numbers
Codebase due diligence
For an owner or an investor looking at a codebase they did not write: ownership, rework, bus factor and what a handover would cost - as questions with the commits attached.
Per repository, with a walkthrough call
Technical advisory
Architecture reviews, model and vendor choices, build or buy, and a second opinion on a plan while changing it is still cheap.
Ongoing, by the hour or by the month
How I work
Six habits that show up in every one of these repositories.
Discovery before code
Read what already exists first - the data, the current process, the business rules nobody wrote down - and catalogue it. What is already there is a specification, not a code reference.
Decisions live next to the code
Every non-obvious call gets a written record with the alternatives and the reason. Six months later the question is answered by the repository, not by memory.
Arguments end in numbers
A golden set, a pinned pipeline, one thing changed at a time. Seven metrics rather than one, because optimising a single number is how a system gets worse while its score improves.
The owner decides the product
Product questions get asked before the implementation, in plain language, with the trade-off spelled out. I do not settle them silently inside a commit.
Plain language reaches the user
Every setting a non-engineer can touch is explained where it sits. Internal names never surface in an interface.
Honest boundaries
What a system cannot do is written down next to what it can. A tool that never says "this one is fine" is not measuring anything, and a promise that quietly outruns the evidence costs more than it wins.
Stack
What I reach for. The list is what these systems actually run on.
- Languages
- TypeScript
- Python
- SQL
- Bash
- Web
- Next.js
- React
- Tailwind
- FastAPI
- Node
- Data
- PostgreSQL
- pgvector
- Postgres FTS
- ltree
- Redis
- Drizzle
- Alembic
- AI
- OpenAI
- Anthropic
- Gemini
- Ollama
- LangGraph
- MCP
- Cross-encoder rerankers
- tree-sitter
- Operations
- Docker
- Helm
- Terraform
- GitHub Actions
- Prometheus
- Grafana
- OpenTelemetry
- Langfuse
- systemd
- Product
- Stripe
- OAuth
- Telegram
- Messenger
- Playwright
- pytest
About
I am an engineer. I take a system from an empty directory to something running in production, and I stay responsible for it after it is running: the schema, the retrieval, the interface, the billing, the deployment and the dashboard that says whether it is healthy.
Reldava Tech is the name my products live under. Everything on this site was built by one person, which is why the case studies talk about trade-offs rather than team size.
Tell me what you are building
A description of the problem is enough to start. If it is a fit I will say what I would build, roughly what it takes, and what I would not do.
Discuss a project