Services
What I take on.
Scoped engineering work that ends with something running in production — not a prototype that needs a second engineer to make real.
Four kinds of work
Complete web products rather than screens. TypeScript and Next.js on the client, Python with FastAPI or Node on the server, PostgreSQL with row-level security underneath. The schema, the endpoints, the auth and the deploy pipeline are part of the delivery, not a follow-up project.
Short, scoped engagements where the deliverable is a thing that runs. Useful when a team needs a defined piece of work taken off the board, or when an idea needs to exist before it can usefully be argued about.
Putting a language model into an existing product without making it fragile. Retrieval over your own data, output structured well enough for the rest of the codebase to rely on, and provider failover so one vendor's rate limit does not become your incident.
Agent systems with the unglamorous parts done: scheduled ingestion, deduplication, classification, and an offline evaluation harness scoring changes against a labelled set — so an improvement can be demonstrated instead of asserted.
The evidence
Every one of these is something I have already shipped and still run. The case studies go into how each was built and where it is weak.
- Frontier — An engineering job board and a morning AI briefing. Frontier reads company career pages every thirty minutes and deletes every posting after seven days.frontier.bymadhav.com ↗
- WRAITH — An autonomous red team for AI applications — it breaks your model before someone else does.wraith.bymadhav.com ↗
- Market Pulse — See what your competitors' customers are begging them to fix.pulse.bymadhav.com ↗
- Nexus Quant — A keyboard-first, command-driven market terminal that runs in a browser tab.nexus.bymadhav.com ↗
- Lead Rescue — An AI receptionist that never misses a lead, day or night.leads.bymadhav.com ↗
How it usually goes
- 1 · Scope. You describe what you are building, where it is now, and what finished looks like. I say plainly whether it is something I should be doing, and what I think it actually costs in effort.
- 2 · Build. Work happens in the open against a running deployment, so progress is something you can click rather than a status update.
- 3 · Hand over. You end up with the code, the deploy path and the reasoning — enough that the next engineer to touch it does not have to reverse-engineer intent.
Start a conversation
Tell me what you are building and where it is stuck.