SShivang Sinha / tech
AI Full-Stack Engineer · M.Sc. NLP

I build AI products
that show their work.

I'm Shivang. I design and ship LLM products end to end, from the React UI and API layer down to the agent graphs, caches and observability underneath. This site covers two of them that are live today: what each one does, how data moves through it, and why I built it that way.

Lensr: AI search, live at lensr.studio DailyAI: AI news, live at dailyai.site
See the products How they differ
01 — Products

Two products, shipped end to end

Both are full-stack apps I built myself, covering frontend, backend, data, deployment and monitoring. Visit the live product, or open the deep dive to follow a request through the system step by step.

lensr.studio ↗

Ask anything and get a structured answer card instead of a page of links.

Lensr works out what you are trying to do (shop, plan a trip, cook, compare), sends the query to one of 35 specialised agents, searches and reads the live web, and streams back a card built for that task, with every source cited. It runs on Azure Container Apps, with Claude on AWS Bedrock.

35intent agents
10purpose-built result cards
SSElive pipeline streaming
query→classify→search→scrape→synthesize→card
Open Lensr ↗ How it works →
dailyai.site ↗

The day's AI news, curated and summarised once, then served instantly.

DailyAI pulls AI stories from news feeds on a schedule, removes duplicates, then runs one LLM pass to select, summarise and tag them. It also scores how trustworthy each source is. Readers get cards straight from the database, so no model call runs when a page loads.

9LangGraph pipeline nodes
0LLM calls per page view
30mdefault refresh cycle
RSS→dedupe→curate→trust→rank→DB→reader
Open DailyAI ↗ How it works →
02 — The key idea

Two ways to spend a model call

Every LLM product has to decide when the model runs. Lensr and DailyAI make opposite choices on purpose, and that one decision shapes their architecture, latency and cost.

Lensr · compute per query

Every question is new

You can't pre-compute an answer to a question nobody has asked yet, so Lensr does the work at request time and makes the wait useful.

cost ≈ queries × (classify + search + synthesize)
  • Streams every step over Server-Sent Events, so you watch it work instead of staring at a spinner.
  • Runs steps in parallel. The web search starts before intent classification finishes.
  • Semantic cache. A similar enough question from the last 24h returns instantly.
  • The model tier follows the mode: Haiku 4.5 for routing and Fast answers, Sonnet 4.6 for Deep research.
DailyAI · compute per refresh

Everyone reads the same news

The day's AI news is the same for every reader, so DailyAI summarises it once and serves the stored result to everyone.

cost ≈ refreshes/day × feeds  (not × readers)
  • A scheduler does the work, not the reader's click. APScheduler refreshes every 30 minutes.
  • Summaries are stored and reused. Briefs are cached per article and language.
  • Can run with no LLM at all. rss mode uses feed summaries and rule-based tagging.
  • Cost stays flat as readership grows. It depends on the refresh interval, not on page views.
03 — Shared engineering

What both products have in common

The products do different jobs, but I built both on the same engineering habits. Each one below is something you can point to in the code.

orchestration

Typed agent graphs

Both pipelines are LangGraph state machines. Each node reads and writes named keys on a typed state object, which makes every step inspectable, testable and easy to reorder.

resilience

Graceful fallbacks

If intent classification times out, Lensr answers as general. DailyAI falls back from one LLM provider to the next, and finally to plain RSS summaries. Users still get an answer when something fails.

cost

Cache the expensive thing

Lensr uses a pgvector semantic cache (Titan embeddings, cosine ≥ 0.88, 24h TTL). DailyAI stores its summaries in the database and reuses them for every reader.

observability

Traced end to end

Every LLM call, tool call and pipeline step is sent as an OpenTelemetry span and grouped by session, to Arize Phoenix for LLM debugging and, for Lensr, also to Azure Application Insights for operations.

security

Secure by default

Secrets kept in Azure Key Vault, parameterised SQL, timing-safe secret comparison, an origin allowlist, an SSRF block-list on the scraper, and non-root Docker images.

delivery

Infrastructure as code, CI/CD

Lensr's whole Azure environment is defined in Bicep. A push to production lints, type-checks and builds, then ships SHA-tagged images to Azure Container Apps. DailyAI ships with Docker, Compose and Render configs.

04 — Stack

Side-by-side stack

LayerLensrDailyAI
FrontendReact 19, TanStack Start/Router, Tailwind v4, shadcn/ui, Framer MotionReact 19, Vite, React Router, installable PWA
APITanStack server routes (SSE proxy) → FastAPIFastAPI (serves both the API and the built SPA)
OrchestrationLangGraph router + 35 per-intent pipelinesLangGraph, 9-node linear news pipeline
ModelsAWS Bedrock (global inference): Claude Sonnet 4.6, Haiku 4.5; Titan embeddingsOpenAI by default; fallback chain across Gemini, Groq, NVIDIA, HF, Ollama
RetrievalSerper (Google SERP) + HTTP/2 trafilatura scraperGoogle News RSS (+ optional Serper News) + scraper
DataAzure PostgreSQL Flexible Server + pgvector, Azure Blob StorageSQLite (default) or Supabase
AuthBetter-Auth: email + Google OAuth, admin rolesAnonymous profiles with a sync code, so no account is needed
ObservabilityArize Phoenix + Azure Application InsightsArize Phoenix (optional) + output-quality score
DeliverySSE stream to the browserWeb, email (Mailgun daily edition), web push
HostingAzure Container Apps (Bicep, Key Vault, GHCR images)Docker / Render / Heroku buildpack
05 — How I work

AI-assisted, engineer-owned

I build with coding agents (Claude Code, Codex, Antigravity), briefed through shared rule files, MCP servers and skill files. Then I hold their output to the same bar as my own: reviewed diffs, quality gates, tests, and LLM evaluations in Phoenix.

agents · MCP · skills

A brief every agent follows

CLAUDE.md, AGENTS.md and GEMINI.md carry the same project rules. An MCP code-graph server and five skill files turn exploring, debugging, refactoring and review into repeatable procedures.

evals · Phoenix

Measured, not eyeballed

Rule-based quality scores on every LLM call, traces with evidence counts per answer, and LLM-as-judge evals for hallucination and relevance on trace datasets.

safety

Grounded and injection-aware

Evidence-only answers with citations, null instead of invention, allow-listed outputs, a prompt-leak sanitiser, and no path from model text to tool permissions.

See how I work → Try the evaluator
06 — About

Hi, I'm Shivang.

I'm an AI full-stack engineer with 5+ years of experience shipping production software: Python/FastAPI backends, React/TypeScript frontends, and the DevOps work that keeps them running.

My focus now is applied LLM systems: retrieval, multi-agent orchestration, evaluation and cost control. I hold an M.Sc. in Natural Language Processing from the University of Trier. My thesis compared NLP models for tracking how AI/ML skill requirements change in the German job market.

Lensr and DailyAI are where I test those ideas with real users.

LinkedIn ↗ GitHub ↗ Email
Where I've worked
  • Carl ZeissBuilt an LLM-powered Microscopy Copilot on Azure.
  • University of TrierM.Sc. Natural Language Processing (thesis completed).
  • BarclaysHigh-reliability transactional systems at 99.9% uptime.
  • HexagonIndustrial platforms serving 500+ users.