Side project
In progresscrack-detector
A multi-turn AI diagnostic that interviews you before it critiques: Java 25 and Spring Boot 4.
Open to work
Tanveer Hoque
Applied AI Engineer · Civica · Cardiff
Applied AI engineer building production LLM systems, with the backend discipline that keeps them cheap, fast and safe
I build the systems that put AI models to work, and then prove what they cost. Nine model providers behind one interface, so an application never has to care which one answers. A spend limit that made the same four tasks 68% cheaper. Underneath it, four years of production Java, including one finance API taken from 99 seconds to under one.
caseIn progress
agent-platform
One OpenAI-compatible endpoint in front of every model, hosted or running on the desk.
- 7 hosted + 2 local
- Upstreams behind one API
- 0 lines
- Provider-specific code in the client
- −68%
- Agent cost
- 9
- Model providers behind one API
- 99s → 0.9s
- API latency
- 4yrs
- In production
The same four tasks, sent to the cheapest model that could still do them. Checked by running the results, not by asking the agents how they did.
Seven hosted services and two running on the machine itself. The application never learns which one answered.
One critical finance endpoint. The slow query was restructured rather than hidden behind a cache.
Java and Spring Boot, finance. Where the operational habits come from.
01
What I build with
The tools in production now. Depth for the rest is one disclosure away.
- Java4 yrs
Languages
Primary language: Spring Boot services, JPA, tests.
- Spring Boot4 yrs
Frameworks
Finance microservices, event listeners, scheduled work.
- PostgreSQL4 yrs
Data & messaging
Finance schemas, query tuning, index work.
- Jenkins4 yrs
Delivery & ops
CI/CD for pre-release and production pipelines, release ownership.
- TypeScript4 yrs
Languages
Node services and every front end since 2022.
- SQL4 yrs
Languages
PostgreSQL: query plans, indexes, Liquibase migrations.
The rest of the stack
Read it · Ships production code · Sets the standard
AI, models & agents
Models & agents
Two different things, kept apart on purpose: models a service of mine calls at runtime, and the assistants I write code with. Both are listed because a claim about either is checkable against a repository.
- Claude Code1 yrs · current
Daily driver. This site and the shared backend behind it were built through it.
- Ollama1 yrs · current
Local models behind agent-platform, reached from inside Docker. No key, no egress.
- OpenAI-compatible APIs1 yrs · current
The /v1 surface agent-platform serves, so any existing client points at it unchanged.
- Cursor2 yrs · current
Languages
What the services are written in, and what the scripts around them are written in.
- JavaScript5 yrs · current
- Rust1 yrs · current
agent-platform: the server, its desktop client, and the LLM proxy inside it.
- Python2 yrs · current
agent-platform’s model-training worker, and the tooling around it.
- Bash4 yrs · current
Build, push, restart: the automation around a deploy.
- C++2 yrs · last used 2019
Algorithms and contest work at university.
Frameworks
Backend first. The front-end entries are there because the same person shipped both ends of these systems.
- Spring Batch4 yrs · current
Payroll estimation and transaction creation jobs.
- JPA / Hibernate4 yrs · current
Where the 99-second query lived.
- Node.js4 yrs · current
- NestJS2 yrs · current
- FastAPI2 yrs · last used 2026
The first agent-platform server, before it was rewritten in Rust.
- Axum / Tokio1 yrs · current
Streaming responses and an OpenAI-compatible surface on one process.
- GraphQL3 yrs · current
- React4 yrs · current
- Next.js3 yrs · current
- Astro1 yrs · current
This site, and the two others that share its backend.
Data & messaging
Where the state lives and how it moves between services.
- RabbitMQ3 yrs · current
Payment flow: queues, retries, dead letters.
- Liquibase4 yrs · current
- MongoDB2 yrs · current
Delivery & operations
Delivery & ops
Getting it out, and knowing what it did once it was out.
- Docker4 yrs · current
- Kubernetes3 yrs · current
Daily on GCP to develop and test; own scripts reduce image build and scaling to one command.
- Google Cloud3 yrs · current
- Vercel2 yrs · current
- GitHub Actions3 yrs · current
Testing & tooling
The parts that decide whether the rest of it can be changed safely.
- JUnit4 yrs · current
- Git6 yrs · current
- Jira4 yrs · current
Scrum and Kanban, estimation, technical-debt stories.
02
Also shipped
The other public cases. Every card opens the write-up.
Open source
Liveclaude-code-plugins
A spend limit an agent cannot lift, and six subagents pinned to the cheapest model that holds.
03
One system, properly
What the finance API was built against, what each decision cost, and what changed.
- client
- service
- store
- queue
Context
A finance microservice in a regulated domain: payments scheduled and settled against records that other services read while it works. The critical read API had degraded to 99 seconds, long past the point where the caller had given up, and the payment path itself was synchronous, so a slow downstream call held the whole request open.
Constraints
- Finance data: nothing may be lost, double-processed or silently retried.
- The schema is shared with services owned by other people, so a migration is a negotiation, not a decision.
- No downtime window: the change had to go out through the same pipeline as everything else.
- The team is small, so whatever replaced it had to be understandable by whoever was on call.
Results
- Critical API response time
- 99s0.9s
- Payment processing
- synchronous request pathevent-driven with visible retries
- Release assembly
- manual stepspipeline, validated pre-release
Decisions
- 01
Fix the query before adding a cache.
Trade-off
Slower to show a result than putting a cache in front of it, and it meant reading query plans rather than writing code.
Why
A cache in front of a 99-second query hides the problem and makes the first request after every eviction just as slow. The plan showed the work being done per row; the fix was structural.
- 02
Move the payment flow to events over RabbitMQ.
Trade-off
Eventual consistency, and a failure path that now has to be designed rather than inherited from the request lifecycle.
Why
A synchronous payment path fails whenever anything downstream is slow. Events let each step retry on its own and make the retry visible in the queue rather than invisible in a thread.
- 03
Schema changes through Liquibase, in the same commit as the code that needs them.
Trade-off
Every change needs a written changeset, including the trivial ones.
Why
A shared schema with hand-applied changes is how environments drift. A changeset makes the migration reviewable and repeatable in the pre-release environment first.
- 04
Build the pre-release environment from the Jenkins pipeline, not by hand.
Trade-off
Pipeline maintenance became part of the job.
Why
The production build is derived from the same commits that passed there. Manual assembly is where a release stops being reproducible.
StackJavaSpring BootJPAPostgreSQLLiquibaseRabbitMQJenkins
04
Contact & access
The public page is the summary. The detailed record is released by an issued link, one recruiter at a time.
Direct line
Get in touch
For a role, a contract, or a question about anything on this page. Replies come from me, not from a form.
- tanvoid0@gmail.com
- Based
- Cardiff, United Kingdom
- GitHub
- github.com/tanvoid0
- Work authorisation
- Authorised to work in the United Kingdom
- Notice period
- One month
If your mail client does not open, write to tanvoid0@gmail.com.
CV
The same facts as this page, laid out the way an applicant tracking system reads them. Built from the public record at deploy time, so it cannot fall behind what the site says.
Open the CVOpens as a document — print or save it as PDF from there. No phone number or postal address on it.
For recruiters & hiring teams
Detailed record access
The CV above is the summary. What a link adds is the part a CV has no room for: per-engagement technical detail, certificates, degree transcripts, and the phone number and postal address the public copy leaves off. Released to one recipient at a time.
- Issued to one person or one company, and revocable at any time.
- Scoped: a link releases only the sections it was issued for.
- Expires, and can be limited to a number of views.
- Optionally tied to the recipient’s email address, so a forwarded link is useless.
Already have a link? Open it directly; no account or sign-in is required. Opening it sets one strictly necessary cookie so the record stays open while you read it; nothing on these public pages sets any. See the privacy notice.