WAQAR GULZAR AI ENGINEER
01 / Front-end, back-end & AI Open for work

I build the interface and the model.

I’m Waqar Gulzar. I work the whole line: the interface people touch, the API behind it, and the model doing the thinking. AI projects usually lose something in the handoff between those three. I own all of it, so the thing that ships is the thing that was designed.

  • Front-end, back-end & AI
  • Your repo, your process
  • Written updates, no fluff
waqar@ai type help · enter
$30per hour
60-80 ha week, shared pool
5-10 htypical first task
24/7what production asks for
02 / What I build

The whole line, not one corner.

Most AI projects do not fail at the prompt. They fail in the plumbing, and then again in the gap between the person who designed the interaction and the person who wired the model into it.

Front-end & interface

Interfaces that feel finished: streaming responses into the message, optimistic state, and real loading, empty and error screens. Keyboard and screen-reader first, then pixels. I am comfortable inside a design system and in pixel-level work.

LLM apps & agents

Tool use, planning loops, memory, human-in-the-loop. Bounded, cancellable, and instrumented so you can see exactly which tool call produced which token.

APIs & data

REST services, databases, auth, payments with real logic. Retrieval on top: chunking that survives messy documents, hybrid search, reranking, permission filters and a refresh path so answers are never stale.

Eval & observability

Golden sets built from real traffic, model-graded rubrics, CI gates that refuse a regression, traces with token and cost attribution per request — plus interface regression tests, because 40 ms is still a regression.

Inference & infra

Streaming, caching, batching, queues, GPU or serverless, rate limits. Fine-tuning and distillation when they pay for themselves. Cost per request is a number I report, not a surprise in the invoice.

Hardening & handover

Auth, secrets, PII redaction, prompt-injection boundaries, timeouts, fallbacks, backfills, and a rollback someone has already rehearsed. Documented, so the next developer picks it up without me.

One person, three layers. The interface, the API and the model are usually three people and two handoffs — and the requirements quietly change in both directions. That is the gap I close.

03 / The path a request takes sample telemetry p95 1.8s · $0.004/req

Where the work actually goes.

Six hops between the user's question and the answer, then the interface that renders it. I own both ends, so the streaming strategy, the latency budget and the loading state get decided together instead of negotiated.

  1. Ingestwebhooks, docs, tickets
  2. Chunkstructure-aware splits
  3. Indexdense + sparse + filters
  4. Retrievehybrid, reranked, cited
  5. Reasonmodel + tools + budget
  6. Evaluaterubric, traces, gates

Latency budget: the first token should not wait for retrieval to fully settle. Skeleton, then answer, then citations.

Failure budget: every hop has a timeout, a fallback and a metric — and the interface has a real state for each one, not a spinner.

04 / Stack

Tools I reach for.

Boring where it should be boring. The interesting decisions belong in the architecture, not in the dependency list.

Interface

  • React
  • Next.js
  • TypeScript
  • Tailwind
  • CSS architecture
  • Design systems
  • Accessibility
  • Streaming UI

Models

  • Open-weight LLMs
  • Hosted APIs
  • LoRA / QLoRA
  • Distillation
  • Routing
  • Prompt caching

Data

  • Postgres + pgvector
  • Hybrid search
  • Rerankers
  • Object storage
  • dbt
  • Message queues

Evaluation

  • Golden sets
  • LLM-as-judge rubrics
  • Regressions in CI
  • Trace spans
  • Cost per request
  • A/B on real traffic

Infrastructure

  • Docker Compose
  • Kubernetes
  • Redis queues
  • CI/CD
  • Prometheus + Grafana
  • restic backups

Practice

  • Threat modelling
  • PII redaction
  • Access control
  • Prompt-injection defence
  • Audit trails
  • Runbooks

Languages

  • TypeScript
  • Python
  • Go
  • SQL
  • Rust
  • Bash
  • CSS
05 / Selected work

Three things, with the numbers attached.

Each entry says what it does, what went wrong along the way, and where it still breaks. A case study without limits is an advertisement.

  1. End to end

    Support copilot: composer, retrieval, model

    One project, three layers, one person. The composer the agents type into, the retrieval behind it, and the model writing the answer — built together so the streaming, the citations and the latency budget were designed rather than negotiated.

    • Tokens stream into the message; the skeleton lands before retrieval settles
    • Citations open the exact source version in place, no round trip to a search page
    • Structure-aware chunking, so a table stays a table
    • A fast path for the 80% of questions that never needed the model at all
    • Permission filters inherited from the source system, enforced before retrieval
  2. Open source

    Agent runner with a hard budget, and a console to watch it

    An execution harness for tool-using agents: every step is a durable record, every run has a wall-clock and token ceiling, and a step that hangs gets killed instead of billing forever. The console reads the same log the runner writes, so the UI can never disagree with the truth.

    • Durable step log in Postgres, so a crash resumes instead of restarting
    • Idempotent tool calls with replay protection
    • Human approval gates for irreversible actions
    • Replay any past run against a new model in one command
    • Live console: steps, tokens, cost and tool calls streaming as they happen
  3. Evaluation

    An eval gate that blocks bad releases

    A regression harness wired into CI. A pull request that changes the model, the prompt or the interface has to pass a golden set, a rubric graded by a model, and a latency, cost and bundle-size check before it merges.

    • Golden set sampled from real traffic, reviewed and versioned
    • Rubric grading with human spot-checks to keep the judge honest
    • Latency, cost and interface performance budgets fail the build, not the dashboard
    • Every release reports the delta, so a regression is obvious

More case studies on request. The full write-ups, including the failure logs, are available on a call.

06 / Now—

What I am doing this month.

Kept short on purpose, and dated, because a "now" page without a date is a lie.

  • BuildingA shared eval harness so three teams stop arguing about which number is right.
  • ReadingEverything published on long-context retrieval, with a bias toward the negative results.
  • LearningInference-side tricks: prefix caching, speculative decoding, and when each one actually pays.
  • Into pixelsView transitions, container queries, and how much of a design system survives contact with a real deadline.
07 / How we work

Small first task. Written everything after.

  1. 01

    Start small

    A first task of five to ten hours. You see how I estimate, communicate and hand over before anything larger is on the table.

  2. 02

    One owner

    The same person from the first wireframe to the last migration. No handoff, no re-explaining, and no “that’s a front-end thing”.

  3. 03

    Your setup

    Your repository, your tracker, your review process, your design system. No new tooling your team has to learn.

  4. 04

    In writing

    Progress, questions and trade-offs go into your tracker or Slack. Calls are audio when a call is genuinely faster.

08 / Rate

$30 / hour

One rate for the interface, the API, the model and the infrastructure. No tiered packages, no discovery fee.

Paid via Payoneer or crypto. Invoiced weekly or monthly.

09 / Availability

60-80 hours a week for your projects

One shared pool for everything, not hours per person. It goes to whoever fits the task.

  • Estimate in hours before any work starts
  • Front-end, back-end and AI — one person, one rate
  • UTC+2 and UTC+5 overlap for most of your day
10 / Contact

Have something that needs to work?

Send a few lines: what it does, what is blocking it, and what a good outcome looks like. I reply with a rough estimate or an honest no.

Email me GitHub LinkedIn

[email protected]