# Sarthak Agrawal — full public corpus Canonical identity: https://sarthakagrawal.dev/#person Website: https://sarthakagrawal.dev --- Source page: https://sarthakagrawal.dev/ # Sarthak Agrawal AI Infrastructure & Product Engineer. I build dependable AI products, from infrastructure to interface. Sarthak Agrawal is an AI infrastructure and product engineer building dependable local tools, model systems, and research products. ## Current work - Software Engineer, Vault Wealth (Feb 2025 — Present): Backend services and reliability infrastructure for a wealth-management platform serving the UAE and Saudi Arabia — financial planning, durable workflows, and the systems they run on. - Software Engineer, Front.Page (Jan 2022 — Jan 2025): Backend and data infrastructure for a fast-growing fintech social product — real-time market data, personalized feeds, and the AI systems layered on top. ## Selected products - [CodeVetter](https://codevetter.com): Execution-backed verification for AI-written software changes — local-first and inspectable. - [PostTrainLLM](https://posttrainllm.com): An experimental browser model playground: run small language models locally with visible generation metrics. - [SaaS Maker](https://sassmaker.com): A public directory of working experiments, launch destinations, reference projects and reusable tooling. ## Canonical identity - Person ID: https://sarthakagrawal.dev/#person - Image: https://avatars.githubusercontent.com/u/43884471?v=4 - Location: India - Linkedin: https://www.linkedin.com/in/sarthakagrawal927 - Github: https://github.com/sarthakagrawal927 - X: https://x.com/sarthakcodes - Email: sarthakagrawal927@gmail.com --- Source page: https://sarthakagrawal.dev/about # About Sarthak Agrawal Sarthak Agrawal is an AI infrastructure and product engineer building dependable local tools, model systems, and research products. ## Experience ### Software Engineer — Vault Wealth Feb 2025 — Present. Backend services and reliability infrastructure for a wealth-management platform serving the UAE and Saudi Arabia — financial planning, durable workflows, and the systems they run on. - Built and own the Go financial-planning backend for the UAE and Saudi markets, including its projection, recommendation, and data-import engines. - Built the retirement and goal projection engine, validated against 68 rolling 30-year S&P 500 periods to within 2% of an independent simulation. - Migrated critical workflows to Temporal, eliminating 90% of unexpected failures and freeing roughly 3 engineering hours every day. - Migrated the web app from MUI to Tailwind and built responsive React components. ### Software Engineer — Front.Page Jan 2022 — Jan 2025. Backend and data infrastructure for a fast-growing fintech social product — real-time market data, personalized feeds, and the AI systems layered on top. - Built a real-time stock-data pipeline with Go, Kafka and Protocol Buffers — supporting DAU growth from 15k to 200k in 14 weeks. - Shipped vector-powered personalized feeds using BERT embeddings, GPT and Milvus, lifting home-feed engagement by 40%. - Built RAG chatbots on OpenAI APIs; the moderation bot cut human intervention in support queries by 90%. - Cut session-refresh DB calls by 92% with queue-based batching and granular session controls; used Redis for O(1) unread-news counts and to cut HTML build+load from 600ms to 60ms. - Integrated the Razorpay payment gateway, opening a new revenue stream and contributing to a 50% increase in overall revenue. - Designed real-time stock ticks over Socket.io with room-based, in-memory and Redis-backed subscription modes. ## Technical focus ### Backend & APIs Getting the service right comes before getting it fast. I care about clean contracts and knowing how things break before they do. Tools: Go, Node.js / TypeScript, Python, Protocol Buffers, REST APIs, Microservices ### Distributed Systems & Reliability Streaming pipelines, durable workflows, real-time delivery — the parts that decide whether a product survives getting popular. Tools: Apache Kafka, Temporal, Socket.io, Queue-based batching, Docker & Kubernetes, Prometheus ### AI / LLM Infrastructure Personalized feeds, retrieval pipelines, agents. The goal is AI that holds up in production, not just in a demo. Tools: RAG pipelines, OpenAI APIs, BERT embeddings, Milvus vector DB, GPT-powered features, Real-time vector enrichment ### Data & Storage Pick storage for how the data actually gets read and written. Then cache the slow paths until they stop being slow. Tools: MySQL, PostgreSQL, Redis, ClickHouse, Elasticsearch, BigQuery ## Education B.Tech, Computer Science and Engineering, Manipal Institute of Technology (Aug 2018 — Jul 2022). --- Source page: https://sarthakagrawal.dev/projects # Projects The selected products below are the primary public work. The full live fleet catalog follows — every maintained product, platform, and experiment with its tier, URL, and description. ## Spotlight products ### CodeVetter Execution-backed verification for AI-written software changes — local-first and inspectable. - Product: https://codevetter.com - Source: https://github.com/Codevetter/codevetter - Organization: https://github.com/Codevetter ### PostTrainLLM An experimental browser model playground: run small language models locally with visible generation metrics. - Product: https://posttrainllm.com - Source: https://github.com/PostTrainLLM/posttrainllm - Organization: https://github.com/PostTrainLLM ### SaaS Maker A public directory of working experiments, launch destinations, reference projects and reusable tooling. - Product: https://sassmaker.com - Source: https://github.com/sass-maker/saas-maker - Organization: https://github.com/sass-maker ## Full fleet catalog 32 live projects across four tiers. SaaS Maker (https://sassmaker.com) is the canonical human-readable directory. ### Featured Shareable work from my primary focus. - **CodeVetter** (focus, P1) — Execution-backed verification for AI-written software changes — local-first and inspectable. URL: https://codevetter.com Repo: https://github.com/Codevetter/codevetter - **PostTrainLLM** (focus, P1) — An experimental browser model playground: run small language models locally with visible generation metrics. URL: https://posttrainllm.com Repo: https://github.com/PostTrainLLM/posttrainllm ### Current work Working public experiments receiving active attention. - **HeyPace** (active, P2) — An experimental macOS voice-agent preview; installation and permission-dependent workflows are still being qualified. URL: https://heypace.app Repo: https://github.com/HeyPace/pace - **Live** (active, P2) — Explore hobbies and possibilities, build a personal bucket list, and save your progress on this device or in your account. URL: https://live.significanthobbies.com Repo: https://github.com/Significant-Hobbies/live - **SaaS Maker** (active, P2) — A public directory of working experiments, launch destinations, reference projects and reusable tooling. URL: https://sassmaker.com Repo: https://github.com/sass-maker/saas-maker - **Memory Map** (active, P2) — A browser-local experiment for importing a ChatGPT export, exploring semantic themes and search, and optionally saving analysis on your device. URL: https://chatgpt.significanthobbies.com Repo: https://github.com/sass-maker/saas-maker - **Free AI** (active, P2) — An OpenAI-compatible free-tier model gateway with operator-provisioned project access. URL: https://ai-gateway.sassmaker.com Repo: https://github.com/sass-maker/free-ai - **High Signal** (active, P2) — Evidence-backed daily intelligence across technology, startups, finance, and public markets. URL: https://highsignal.app Repo: https://github.com/High-Signal-App/high-signal - **Knowledge Base** (active, P2) — Private agent search over specialized corpora with ranked citations, provenance, and schema-aware retrieval. URL: https://knowledgebase.sassmaker.com Repo: https://github.com/sass-maker/knowledge-base Domains: knowledgebase.sassmaker.com, search.sassmaker.com - **Significant Hobbies** (active, P2) — The shared Hub for Live, Calorie, Setline, Kith, and Anchor, backed by one privacy-aware control plane. URL: https://significanthobbies.com Repo: https://github.com/Significant-Hobbies/significanthobbies - **Anime List** (active, P2) — Anime and manga discovery with multi-axis filtering and personal watchlists. URL: https://anime.significanthobbies.com Repo: https://github.com/Significant-Hobbies/anime-list - **LoopTV** (active, P2) — An experimental lean-back queue of curated science and other videos. URL: https://tv.significanthobbies.com Repo: https://github.com/Significant-Hobbies/looptv - **SWE Interview Prep** (active, P2) — A learning OS for software-engineering interview practice. URL: https://learn.significanthobbies.com Repo: https://github.com/Significant-Hobbies/swe-interview-prep - **Calorie** (active, P2) — A private, local-first food, water, and weight journal with transparent timing guidance. URL: https://calorie.significanthobbies.com Repo: https://github.com/Significant-Hobbies/calorie - **Setline** (active, P2) — An iOS-native training tracker that runs a written strength, cardio and mobility programme one set at a time and measures each exercise against an authored target. URL: https://setline.significanthobbies.com Repo: https://github.com/Significant-Hobbies/setline - **Kith** (active, P2) — A private iPhone app for the people you actually want to stay close to — closeness-weighted constellation home, standing notes, and a chronological log per person. URL: https://kith.significanthobbies.com Repo: https://github.com/Significant-Hobbies/kith - **RolePatch** (active, P2) — A guest resume-tailoring experiment with a reviewable diff and browser-local document exports. URL: https://rolepatch.com Repo: https://github.com/Significant-Hobbies/rolepatch - **Karte** (active, P2) — A creator-owned public profile that answers visitor questions and preserves context for better inbound. URL: https://karte.cc Repo: https://github.com/Significant-Hobbies/karte - **Starboard** (active, P2) — Explore public GitHub repositories and related projects through a searchable discovery experiment. URL: https://starboard.codevetter.com Repo: https://github.com/Codevetter/starboard - **App Health** (active, P2) — Web analytics, product events, logs, and endpoint health in one workspace. URL: https://health.sassmaker.com Repo: https://github.com/sass-maker/app-health Domains: health.sassmaker.com, ingest.sassmaker.com - **Web Playables** (active, P2) — Small browser-playable game experiments. URL: https://idle.aliveville.com Repo: https://github.com/sarthakagrawal927/web-playables Domains: idle.aliveville.com, historia.aliveville.com - **Paths** (active, P2) — Explore sourced career turning points with explicit survivorship and forecasting limits. URL: https://paths.significanthobbies.com Repo: https://github.com/Significant-Hobbies/what-it-takes-to-win - **Sarthak Agrawal** (active, P2) — Selected engineering case studies, technical writing and working project demonstrations. URL: https://sarthakagrawal.dev Repo: https://github.com/sarthakagrawal927/portfolio - **Anchor** (active, P2) — A local-first day planner and focus timer for Mac, iPhone, and Apple Watch that explains the gap between the schedule you planned and the day you lived. URL: https://anchor.significanthobbies.com Repo: https://github.com/Significant-Hobbies/anchor - **storagedaddy** (active, P2) — An open-source native Mac storage analyzer for developer caches, builds, dependencies and AI session archives, with reviewed cleanup. Free during early access. URL: https://storage.daddyrad.com/ Repo: https://github.com/Significant-Hobbies/storagedaddy Domains: storage.daddyrad.com, storagedaddy.significanthobbies.com - **BrowserDaddy** (active, P2) — A local-first Mac browsing intelligence app for a unified history archive and real attention tracking. URL: https://browser.daddyrad.com/ Repo: https://github.com/Significant-Hobbies/browserdaddy Domains: browser.daddyrad.com, browserdaddy.significanthobbies.com - **PerformanceDaddy** (active, P2) — A local Mac performance investigator for background apps, helpers and developer workloads, with measured evidence and reviewed actions. URL: https://performance.daddyrad.com/ Repo: https://github.com/Significant-Hobbies/performancedaddy Domains: performance.daddyrad.com, performancedaddy.significanthobbies.com - **ContextDaddy** (active, P2) — A native Mac workspace for coding-agent skills, context, usage and telemetry, with a unified skill library, explicit local changes, and recovery history. URL: https://context.daddyrad.com/ Repo: https://github.com/Significant-Hobbies/contextdaddy ### Past work Useful retained work without an active development commitment. - **AI Badges** (parked, P2) — Embeddable README badges for declaring AI contribution and welcoming AI-assisted pull requests. URL: https://github.com/sarthakagrawal927/ai-badges Repo: https://github.com/sarthakagrawal927/ai-badges - **Pinpoint** (parked, P2) — A local developer preview for selecting an app element, attaching a comment and handing context to a coding agent. URL: https://github.com/sarthakagrawal927/pinpoint Repo: https://github.com/sarthakagrawal927/pinpoint - **Port Whisperer** (parked, P2) — A command-line port scanner with framework detection and structured output for local development. URL: https://github.com/sarthakagrawal927/port-whisperer Repo: https://github.com/sarthakagrawal927/port-whisperer - **Society Relay** (parked, P2) — A fixture-driven community repair-planning experiment with human approval, work orders and calendar export. URL: https://github.com/sarthakagrawal927/society-relay Repo: https://github.com/sarthakagrawal927/society-relay --- Source page: https://sarthakagrawal.dev/resume # Sarthak Agrawal — Backend & AI Infrastructure Engineer Location: India Email: sarthakagrawal927@gmail.com LinkedIn: https://www.linkedin.com/in/sarthakagrawal927 GitHub: https://github.com/sarthakagrawal927 PDF: https://sarthakagrawal.dev/resume.pdf Other versions: https://sarthakagrawal.dev/resume/backend, https://sarthakagrawal.dev/resume/full-stack Backend and AI infrastructure engineer with 4+ years building production services, real-time data pipelines, LLM agents, and developer tools in Go, Python, TypeScript, and Rust. Own a Go financial-planning backend, shipped systems that scaled from 15K to 200K DAU, and build AI pipelines where models transcribe and code does the math. ## Experience ### Software Engineer — Vault Wealth Feb 2025 — Present · Peak XV-backed Wealth-management fintech serving the UAE and Saudi Arabia - Built and own the Go financial-planning backend for the UAE and Saudi markets, from its API and scheduled jobs to the projection, recommendation, and data-import engines below. - Built the retirement and goal projection engine, validated against 68 rolling 30-year S&P 500 periods (1928–2024) to within 2% of an independently written simulation; merged three diverging engine versions into one. - Built a recommendations engine that precomputes every option’s what-if result, so the numbers always match what the client sees on click: 0 mismatches across 1,416 options on real accounts, at 18 ms per account. It replaced a 20-type system in which only 7 types ever fired. - Built a pre-merge safety net that replays every planning-engine change against a copy of all client profiles and diffs it with production, plus a 50,000-case randomized test that money is never created or lost; together they caught bugs unit tests missed, including a seven-figure double count of retirement savings. - Replaced random-return simulations with replays of real market crises (1929, 1973, the dot-com crash, 2008) across 7 asset classes using 1928–2025 data, exposing that the old model overstated diversification and nearly halving worst-case cushions once modelled correctly. - Built AI document-import pipelines where the model can’t get the math wrong: the model only transcribes and labels, while Go code does the arithmetic and checks it against the statement’s running balance; 893 of 895 transactions reconciled to the smallest currency unit. Also built a monthly fund-factsheet pipeline with Claude. - Migrated critical workflows to Temporal, eliminating 90% of unexpected failures and freeing about 3 engineering hours per day. - Cut the release end-to-end test gate from about 80 minutes (it timed out on every release) to about 7, with 315 tests passing after fixing 48 already failing on main; made the local suite 12.8× faster (30 to 2.5 minutes) and freed about 363 CI minutes a day. ### Software Engineer — Front.Page Jan 2022 — Jan 2025 · YC S’21 - Built a real-time stock-data pipeline with Go, Kafka, and Protocol Buffers, supporting product growth from 15K to 200K DAU in 14 weeks. - Built RAG assistants on OpenAI APIs for support, learning, and general help; the moderation bot reduced human intervention in support queries by 90%. - Built a personalized-feed pipeline using BERT embeddings, Milvus, GPT calls, and real-time BigQuery events for richer user vectors, increasing home-feed engagement by 40%. - Added queue-based batching and granular session controls, reducing session-refresh database calls by 92%. - Cut HTML build and load time from 600 ms to 60 ms with Redis caching, improving SEO performance. - Launched a Hot News feed with read/unread and last-visit tracking, aggregating events through RudderStack and ClickHouse; tripled average news scroll count in 3 weeks. - Designed real-time stock-tick delivery over Socket.IO with room-based, in-memory, and Redis-backed subscription modes, connected to web clients through window events. ## Selected projects ### PostTrainLLM — Mac-first LLM factory, runtime, and evaluation platform Stack: Swift/MLX, Python, TypeScript/WebGPU, C++/WASM Link: https://github.com/PostTrainLLM/posttrainllm - Built a local Swift/MLX pipeline for data preparation, post-training (LoRA, distillation), evaluation gates, trace capture, packaging, and OpenAI-compatible serving, with Python reference implementations and a browser WebGPU/WASM runtime. - Implemented a KV-cached multi-turn agent runtime over OpenAI tool schemas with bounded steps, per-tool timeouts, output limits, and JSONL audit transcripts. - Distilled a 4B specialist from ~99 frontier rollouts that scored 100% on a frontier-validated hard multi-turn tool-calling gate. ### CodeVetter — Local-first verification layer for agent-generated code Stack: Rust, SQLite, SwiftUI, MCP Link: https://github.com/Codevetter/codevetter - Shipped a native SwiftUI macOS workbench backed by a Rust CLI and SQLite that runs provider-neutral coding agents, persists findings with execution evidence, and drives fix, re-review, and verification-handoff loops. - Built a read-only Rust MCP server with scoped graph/history tools, versioned resources, concurrency limits, secret filtering, bounded responses, and audit history; ~2.2 ms p50 steady queries on a 10K-event fixture. ### Pace — On-device, screen-aware Mac voice agent Stack: Swift, MLX, local LLM planners, streaming TTS Link: https://github.com/HeyPace/pace - Built an 8-step plan-act-observe loop over local planners (OpenAI-compatible servers, MLX, Apple Foundation Models) for screen-grounded click, type, scroll, and keyboard actions. - Added model prewarming, prompt caching, screen-pixel hashing, and streaming sentence TTS, targeting a sub-500 ms first spoken response. ## Skills - **Languages:** Go, Python, TypeScript/JavaScript, Rust, C/C++ - **LLM & Agents:** OpenAI-compatible APIs, function/tool calling, MCP, agent orchestration, RAG, embeddings/vector search, evaluation, local inference (MLX) - **Backend & Data:** REST APIs, microservices, Kafka, Protocol Buffers, Temporal, MySQL, PostgreSQL, SQLite, Redis, Elasticsearch, ClickHouse, BigQuery, Milvus - **Infrastructure:** Linux, Docker, Kubernetes, AWS, GCP, Cloudflare Workers, Prometheus, GitHub Actions ## Education B.Tech, Computer Science and Engineering, Manipal Institute of Technology (Aug 2018 — Jul 2022). Coursework: Algorithms, Data Structures, DBMS, OOP, Operating Systems, Computer Networks. Built several internal college portals (recommendations, placement, fest, library management). --- Source page: https://sarthakagrawal.dev/resume/backend # Sarthak Agrawal — Backend Software Engineer Location: India Email: sarthakagrawal927@gmail.com LinkedIn: https://www.linkedin.com/in/sarthakagrawal927 GitHub: https://github.com/sarthakagrawal927 PDF: https://sarthakagrawal.dev/resume-backend.pdf Other versions: https://sarthakagrawal.dev/resume, https://sarthakagrawal.dev/resume/full-stack Backend engineer with 4+ years building production services, real-time data pipelines, and durable workflows in Go, Node.js/TypeScript, and Python. Own a Go financial-planning backend validated against 96 years of market history, built a Kafka stock-data pipeline that scaled from 15K to 200K DAU, and cut workflow failures by 90% with Temporal. ## Experience ### Software Engineer — Vault Wealth Feb 2025 — Present · Peak XV-backed Wealth-management fintech serving the UAE and Saudi Arabia - Built and own the Go financial-planning backend for the UAE and Saudi markets, from its API and scheduled jobs to the projection, recommendation, and data-import engines below. - Built the retirement and goal projection engine, validated against 68 rolling 30-year S&P 500 periods (1928–2024) to within 2% of an independently written simulation; merged three diverging engine versions into one. - Built a recommendations engine that precomputes every option’s what-if result, so the numbers always match what the client sees on click: 0 mismatches across 1,416 options on real accounts, at 18 ms per account. It replaced a 20-type system in which only 7 types ever fired. - Built a pre-merge safety net that replays every planning-engine change against a copy of all client profiles and diffs it with production, plus a 50,000-case randomized test that money is never created or lost; together they caught bugs unit tests missed, including a seven-figure double count of retirement savings. - Replaced random-return simulations with replays of real market crises (1929, 1973, the dot-com crash, 2008) across 7 asset classes using 1928–2025 data, exposing that the old model overstated diversification and nearly halving worst-case cushions once modelled correctly. - Integrated Lean open banking for the UAE and Saudi Arabia with signed webhooks and Temporal sync jobs, and built an in-house transaction-categorization pipeline for accurate spending analysis. - Built AI document-import pipelines where the model can’t get the math wrong: the model only transcribes and labels, while Go code does the arithmetic and checks it against the statement’s running balance; 893 of 895 transactions reconciled to the smallest currency unit. Also built a monthly fund-factsheet pipeline with Claude. - Added direct GCC market-data feeds for Tadawul, ADX, DFM, and Nasdaq Dubai, plus 348 Saudi mutual funds the existing market-data vendor doesn’t cover, at no extra vendor cost. - Migrated critical workflows to Temporal, eliminating 90% of unexpected failures and freeing about 3 engineering hours per day. - Cut the release end-to-end test gate from about 80 minutes (it timed out on every release) to about 7, with 315 tests passing after fixing 48 already failing on main; made the local suite 12.8× faster (30 to 2.5 minutes) and freed about 363 CI minutes a day. ### Software Engineer — Front.Page Jan 2022 — Jan 2025 · YC S’21 - Built a real-time stock-data pipeline with Go, Kafka, and Protocol Buffers, supporting product growth from 15K to 200K DAU in 14 weeks. - Built RAG assistants on OpenAI APIs for support, learning, and general help; the moderation bot reduced human intervention in support queries by 90%. - Built a personalized-feed pipeline using BERT embeddings, Milvus, GPT calls, and real-time BigQuery events for richer user vectors, increasing home-feed engagement by 40%. - Added queue-based batching and granular session controls, reducing session-refresh database calls by 92%. - Cut HTML build and load time from 600 ms to 60 ms with Redis caching, improving SEO performance. - Built a Node.js and MySQL (Prisma) microservice to manage the complete lifecycle of stock-fundamentals data. - Launched a Hot News feed with read/unread and last-visit tracking, aggregating events through RudderStack and ClickHouse; tripled average news scroll count in 3 weeks. - Served unread-news and global-notification counts in O(1) time and space using Redis. - Designed real-time stock-tick delivery over Socket.IO with room-based, in-memory, and Redis-backed subscription modes, connected to web clients through window events. - Implemented FCM topic-based notifications, reducing delivery time by 90% and increasing delivery rate by 30%. - Integrated Razorpay payments in Node.js, opening a new revenue stream and contributing to a 50% increase in overall revenue. ## Selected projects ### PostTrainLLM — Mac-first LLM factory, runtime, and evaluation platform Stack: Swift/MLX, Python, TypeScript/WebGPU, C++/WASM Link: https://github.com/PostTrainLLM/posttrainllm - Built a local Swift/MLX pipeline for data preparation, post-training (LoRA, distillation), evaluation gates, trace capture, packaging, and OpenAI-compatible serving, with Python reference implementations and a browser WebGPU/WASM runtime. - Implemented a KV-cached multi-turn agent runtime over OpenAI tool schemas with bounded steps, per-tool timeouts, output limits, and JSONL audit transcripts. ### CodeVetter — Local-first verification layer for agent-generated code Stack: Rust, SQLite, SwiftUI, MCP Link: https://github.com/Codevetter/codevetter - Shipped a native SwiftUI macOS workbench backed by a Rust CLI and SQLite that runs provider-neutral coding agents, persists findings with execution evidence, and drives fix, re-review, and verification-handoff loops. - Built a read-only Rust MCP server with scoped graph/history tools, versioned resources, concurrency limits, secret filtering, bounded responses, and audit history; ~2.2 ms p50 steady queries on a 10K-event fixture. ### Stumble — Location-based social app Stack: Node.js, PostgreSQL/PostGIS, Redis, Flutter, Docker, AWS - Launched an app for meeting people nearby, with real-time chat, location-based profile filtering, face recognition, Google sign-in, and push notifications. ## Skills - **Languages:** Go, Python, TypeScript/JavaScript, Rust, C/C++ - **Backend & Data:** REST APIs, microservices, Kafka, Protocol Buffers, Temporal, MySQL, PostgreSQL, SQLite, Redis, Elasticsearch, ClickHouse, BigQuery, Milvus - **AI:** RAG, embeddings, OpenAI APIs, MCP - **Infrastructure:** Linux, Docker, Kubernetes, AWS, GCP, Cloudflare Workers, Prometheus, GitHub Actions ## Education B.Tech, Computer Science and Engineering, Manipal Institute of Technology (Aug 2018 — Jul 2022). Coursework: Algorithms, Data Structures, DBMS, OOP, Operating Systems, Computer Networks. Built several internal college portals (recommendations, placement, fest, library management). --- Source page: https://sarthakagrawal.dev/resume/full-stack # Sarthak Agrawal — Full-Stack Software Engineer Location: India Email: sarthakagrawal927@gmail.com LinkedIn: https://www.linkedin.com/in/sarthakagrawal927 GitHub: https://github.com/sarthakagrawal927 PDF: https://sarthakagrawal.dev/resume-full-stack.pdf Other versions: https://sarthakagrawal.dev/resume, https://sarthakagrawal.dev/resume/backend Full-stack engineer with 4+ years shipping products end to end: Go and Node.js services, React and Tailwind front ends, real-time features over Socket.IO, payments, and notifications. Shipped an English/Arabic right-to-left fintech app, helped a consumer fintech app grow from 15K to 200K DAU, and launched personal products on web and mobile. ## Experience ### Software Engineer — Vault Wealth Feb 2025 — Present · Peak XV-backed Wealth-management fintech serving the UAE and Saudi Arabia - Built and own the Go financial-planning backend for the UAE and Saudi markets, from its API and scheduled jobs to the projection, recommendation, and data-import engines below. - Built the retirement and goal projection engine, validated against 68 rolling 30-year S&P 500 periods (1928–2024) to within 2% of an independently written simulation; merged three diverging engine versions into one. - Built a recommendations engine that precomputes every option’s what-if result, so the numbers always match what the client sees on click: 0 mismatches across 1,416 options on real accounts, at 18 ms per account. It replaced a 20-type system in which only 7 types ever fired. - Integrated Lean open banking for the UAE and Saudi Arabia with signed webhooks and Temporal sync jobs, and built an in-house transaction-categorization pipeline for accurate spending analysis. - Built AI document-import pipelines where the model can’t get the math wrong: the model only transcribes and labels, while Go code does the arithmetic and checks it against the statement’s running balance; 893 of 895 transactions reconciled to the smallest currency unit. Also built a monthly fund-factsheet pipeline with Claude. - Migrated critical workflows to Temporal, eliminating 90% of unexpected failures and freeing about 3 engineering hours per day. - Cut the release end-to-end test gate from about 80 minutes (it timed out on every release) to about 7, with 315 tests passing after fixing 48 already failing on main; made the local suite 12.8× faster (30 to 2.5 minutes) and freed about 363 CI minutes a day. - Translated the app into English and Arabic with right-to-left layout, taking hardcoded strings from 9,308 to 0 across 5,844 translation keys, with a build check that fails on untranslated text. - Built out the Storybook design system, brought web and iOS to 94.8% visual match across 78 screens, and migrated the web app from MUI to Tailwind. ### Software Engineer — Front.Page Jan 2022 — Jan 2025 · YC S’21 - Built a real-time stock-data pipeline with Go, Kafka, and Protocol Buffers, supporting product growth from 15K to 200K DAU in 14 weeks. - Built RAG assistants on OpenAI APIs for support, learning, and general help; the moderation bot reduced human intervention in support queries by 90%. - Built a personalized-feed pipeline using BERT embeddings, Milvus, GPT calls, and real-time BigQuery events for richer user vectors, increasing home-feed engagement by 40%. - Added queue-based batching and granular session controls, reducing session-refresh database calls by 92%. - Cut HTML build and load time from 600 ms to 60 ms with Redis caching, improving SEO performance. - Built a Node.js and MySQL (Prisma) microservice to manage the complete lifecycle of stock-fundamentals data. - Launched a Hot News feed with read/unread and last-visit tracking, aggregating events through RudderStack and ClickHouse; tripled average news scroll count in 3 weeks. - Served unread-news and global-notification counts in O(1) time and space using Redis. - Designed real-time stock-tick delivery over Socket.IO with room-based, in-memory, and Redis-backed subscription modes, connected to web clients through window events. - Implemented FCM topic-based notifications, reducing delivery time by 90% and increasing delivery rate by 30%. - Integrated Razorpay payments in Node.js, opening a new revenue stream and contributing to a 50% increase in overall revenue. ## Selected projects ### CodeVetter — Local-first verification layer for agent-generated code Stack: Rust, SQLite, SwiftUI, MCP Link: https://github.com/Codevetter/codevetter - Shipped a native SwiftUI macOS workbench backed by a Rust CLI and SQLite that runs provider-neutral coding agents, persists findings with execution evidence, and drives fix, re-review, and verification-handoff loops. ### Stumble — Location-based social app Stack: Node.js, PostgreSQL/PostGIS, Redis, Flutter, Docker, AWS - Launched an app for meeting people nearby, with real-time chat, location-based profile filtering, face recognition, Google sign-in, and push notifications. ### Significant Hobbies — Life management app Stack: Next.js, Go, PostgreSQL, Tailwind, Docker, AWS Link: https://significanthobbies.com - Launched a personal productivity app for tasks, habits, food logs, journals, and schedules, with custom form validation and preference-based schedule generation. ## Skills - **Languages:** TypeScript/JavaScript, Go, Python, Dart, Swift - **Frontend & Mobile:** React, Next.js, Astro, Tailwind CSS, MUI, Socket.IO, Flutter - **Backend & Data:** Node.js, REST APIs, Prisma, MySQL, PostgreSQL/PostGIS, Redis, Kafka, Temporal, ClickHouse, BigQuery - **AI:** RAG, embeddings, OpenAI APIs, MCP - **Infrastructure:** Docker, AWS, GCP, Cloudflare Pages/Workers, Firebase (FCM), GitHub Actions ## Education B.Tech, Computer Science and Engineering, Manipal Institute of Technology (Aug 2018 — Jul 2022). Coursework: Algorithms, Data Structures, DBMS, OOP, Operating Systems, Computer Networks. Built several internal college portals (recommendations, placement, fest, library management). --- Source page: https://sarthakagrawal.dev/blog # Writing by Sarthak Agrawal Technical notes about AI infrastructure, distributed systems, product engineering, and operating a public software fleet. - [Attention Is All You Need. Twice.](https://sarthakagrawal.dev/blog/attention-is-all-you-need-twice): LLMs are the production engine of a modern business; marketing is its distribution and sensing engine. A useful product that nobody notices barely exists — so attention matters twice: once in the model, once in the market. - [How I run 23 products on Cloudflare without Argo](https://sarthakagrawal.dev/blog/fleet-performance-without-argo): A personal fleet on Workers and Pages had fast *.workers.dev URLs and slow custom domains. Here is the perf push that closed desktop LCP p75 under 500 ms — measured with distributional Lighthouse runs, not a single PageSpeed score. --- Source page: https://sarthakagrawal.dev/blog/attention-is-all-you-need-twice # Attention Is All You Need. Twice. LLMs are the production engine of a modern business; marketing is its distribution and sensing engine. A useful product that nobody notices barely exists — so attention matters twice: once in the model, once in the market. The strange thing about the LLM era is that it has made building easier without making business easier. A single person can now take an idea much further than they could a few years ago. Coding is faster, research is faster, and the first draft of almost everything is cheaper. But this leverage is available to everyone. The result is not less competition. It is a flood of competent products fighting for the same limited amount of human attention. That is why the title *Attention Is All You Need* now feels relevant in two different ways. In an LLM, attention helps the model decide which parts of its context matter. In business, marketing determines whether a product gets a chance to matter at all. A useful product that nobody notices receives no users, no feedback, and no revenue. It may be good, but from the market's point of view, it barely exists. For a long time, builders treated marketing as the work that began after the real work was finished. You built the product, polished it, and eventually announced it. That model is becoming obsolete. Marketing is not just promotion. It is how a business learns what people care about, how they describe their problems, what they ignore, what they share, and what they are willing to pay for. Those reactions are not separate from product development; they are among its most valuable inputs. This is why LLMs and marketing belong together. LLMs are becoming the production engine of a modern business, while marketing is becoming its distribution and sensing engine. One allows a small team to create and test far more ideas. The other tells that team which ideas deserve to survive. The useful loop is no longer to build privately for months and then hope people care. It is to build, put the work in front of people, observe the response, and use that response to decide what comes next. A business that understands LLMs but ignores marketing can produce an impressive amount of invisible work. A business that understands marketing but has nothing useful behind it may capture attention briefly, but it will not keep it. The durable advantage comes from combining the two: using machines to create value at unusual speed, then earning enough human attention to discover whether that value actually matters. Attention is not literally everything a business needs. It still has to become trust, retention, and revenue. But it is the first gate. The machine has to pay attention well enough to help create something useful, and people have to pay attention long enough to discover that it is useful. **Attention is all you need. Twice.** --- Source page: https://sarthakagrawal.dev/blog/fleet-performance-without-argo # How I run 23 products on Cloudflare without Argo A personal fleet on Workers and Pages had fast *.workers.dev URLs and slow custom domains. Here is the perf push that closed desktop LCP p75 under 500 ms — measured with distributional Lighthouse runs, not a single PageSpeed score. I ship a lot of small products — 23 live sites on Cloudflare Workers and Pages, mostly solo. The fleet had a split personality: `*.workers.dev` and `*.pages.dev` URLs were fast, but custom domains sat on a **400–1000 ms TTFB floor**. PageSpeed Insights gave me one number per URL. That number lied often enough that I built [psi-swarm](https://github.com/sass-maker/psi-swarm) to run Lighthouse many times and report **p50/p75/p90/p99** instead. This post is the narrative version. The structured case study with baseline, tactics, and results lives on [SaaS Maker](https://sassmaker.com). ## The constraint No Argo Smart Routing. No Vercel migration. Goal: **desktop LCP p75 under 500 ms** across the inventory. That sounds like a CDN problem until you look at the breakdown. On several Worker homepages, TTFB on a custom domain was 2–3× the same route on `*.workers.dev`. Cloudflare's free tier routing is real; fighting it with more JavaScript is not. ## What actually moved LCP **1. Astro static overlays for marketing `/` routes** Several apps are Next.js or React on Workers. The app shell is fine for logged-in flows; the landing page does not need SSR on every request. I added thin Astro sites that serve static HTML at `/` and link into the app. Same product behind the URL, but the LCP element is plain HTML at the edge — not a hydration waterfall. **2. Self-hosted fonts** Google Fonts CSS is render-blocking and adds DNS + connection setup. Moving to `@fontsource` (self-hosted, subsetted) removed a recurring 200–400 ms delay on mobile-slow presets. **3. Killed opacity-0 hero animations** This one hurt to admit. Framer Motion fade-ins on above-the-fold heroes were **40–70% of LCP render delay** on multiple sites. The hero image loaded; the browser waited to paint it because opacity was zero until JS ran. Removing or deferring those animations was often a bigger win than image compression. **4. Edge cache for semi-dynamic Worker homepages** For routes that cannot go fully static, `Cache-Control` headers plus `caches.default` in a thin worker wrapper let repeat visitors hit cached HTML. Not a substitute for static where static fits — but it trimmed TTFB on homepages that still need a Worker. **5. Distributional measurement** Single Lighthouse runs are noisy. psi-swarm runs the same URL across realistic device/network presets, stores history in SQLite, and surfaces regressions in a `/projects` dashboard. I stopped optimizing for one green PSI score and started watching **p75 LCP** week over week. ## Results Five sites closed under 500 ms desktop LCP p75 in the first push. The remaining gap is app-level TTFB on custom domains — a known Workers floor without paid routing. The wins were front-end and architecture choices I could ship in a week, not magic CDN settings. ## Try the tooling - **[psi-swarm](https://github.com/sass-maker/psi-swarm)** — CLI + local UI; runs stay on your machine - **[SaaS Maker](https://sassmaker.com)** — the broader fleet directory - **[Fleet products hub](https://sarthakagrawal.dev/projects)** — all ten root domains in one place If you are running a personal product fleet on Cloudflare, the highest-leverage move is usually: **static HTML at `/`, measure p75 not p50, and delete the hero fade-in.** Everything else is incremental. --- Source page: https://sarthakagrawal.dev/privacy # Privacy This is a static portfolio site. It has no account system, application database, advertising tracker, or user-content upload. The site may fetch public GitHub repository metadata at build time. Visiting linked products or external profiles is governed by those destinations. Contact: sarthakagrawal927@gmail.com --- Source page: https://sarthakagrawal.dev/work/posttrainllm # PostTrainLLM — a transformer built end to end, then a local LLM factory A small GPT (~0.8M params, byte-level) written from scratch in three layers — a PyTorch reference, a hand-derived C++/WASM implementation, and a full WebGPU training loop — running entirely in a browser tab. Every layer's backward pass was finite-difference checked before being trusted. It has since grown into a Mac-first LLM factory and runtime, where a 4B model distilled from ~99 frontier rollouts scored 100% on a hard multi-turn tool-calling gate. Role: Personal · Learning by building Year: 2026 Stack: PyTorch, C++, WebAssembly, WebGPU / WGSL, TypeScript, Swift / MLX Source: https://github.com/PostTrainLLM/posttrainllm Demo: https://posttrainllm.com ## The problem Most people who use transformers can describe attention with a diagram but couldn't write its backward pass from memory. I was one of them. Calling an LLM API doesn't teach you how it works; even idiomatic PyTorch mostly teaches you *its API*, not the underlying maths. So I set the bar: a working transformer, trainable from scratch in a browser tab, with **no autograd anywhere in the WASM and WebGPU paths**. Every layer something I'd written, derived, and tested. ## Architecture The same model exists at three levels, in build order: - **`python_ref/`** — a PyTorch reference: model, training loop, sampler, LoRA, evaluation. ~200 lines of clear code; the source of truth everything else is compared against. - **`wasm/`** — the same model in C++, with every backward pass *derived and written by hand*. There is no autograd. Compiled to WebAssembly with Emscripten; built twice — scalar and `-msimd128` for SIMD autovectorization. - **`webgpu/`** — full forward, backward, and AdamW on the GPU in WGSL. Tensors stay resident in GPU buffers between ops; a buffer pool reuses them across steps; an entire training step records into one command submission. A browser app picks a backend (WASM or WebGPU), trains in a Web Worker so the page never freezes, samples from the model, and checkpoints to OPFS so a run survives a refresh. ## Engineering decisions The principle throughout: **every layer had to be testable before it was trusted.** Each kernel has a finite-difference gradient check against a reference implementation; each model has an "overfit gate" — train on a single batch, the cross-entropy loss must collapse to near-zero or the build doesn't ship. That one property is what made writing a hand-derived WebGPU backward pass tractable. Bugs were caught at the layer they lived in, not three layers later as a mystery in the loss curve. The three implementations were built in that order on purpose: the PyTorch reference exists so the C++ has something to be wrong against; the C++ overfit gate exists so the WebGPU does too. Each level pins the next. The WebGPU training port itself went in as six staged pull requests — GPU tensors and matmul, the elementwise ops, attention, embeddings + cross-entropy + AdamW, the orchestrator, the app integration — each parity-checked against WASM before the next began. When everything is verifiable, the diffs stay small and the bugs stay local. One note on honesty. An earlier write-up of mine documented WebGPU training as ~2× slower than WASM based on automated measurements; I later discovered the headless CI was using `swiftshader`, a **software** WebGPU adapter, so the comparison was software-WebGPU racing SIMD-WASM — not a valid GPU number. The doc was corrected, the claim withdrawn, and the real-hardware speed left explicitly unmeasured until it could be measured properly. The project's whole method was "verify before claiming"; that was a miss against it, fixed in the open. A later paired ABBA run on an Apple M5 Pro measured WebGPU at a 10.67× median speedup over WASM on the Large preset, with at most 4.72% final-loss drift between backends. ## Outcome A complete transformer that runs in a browser tab — ~0.8M params, byte-level, trains from scratch, generates samples, survives a refresh. The overfit gate sits at cross-entropy 5.55 → 0.002. The SIMD WASM build trains at ~1.6× the scalar speed. The WebGPU training loop is correct end to end (24/24 kernels parity-checked, the GPU overfit gate passes), and on real Apple silicon it trains the Large preset 10.67× faster than WASM. The model itself is too small to write coherent prose and is meant to be. The point of the project was the learning trail behind it kept visible — the write-ups, the staged PRs, every layer's test. That part worked. ## What it became The browser model was the start, not the end. The same verify-first habit carried into a Mac-first LLM factory built on MLX-Swift: data preparation, LoRA post-training and distillation, eval gates, trace capture, packaging, and an OpenAI-compatible local server with a KV-cached, bounded multi-turn agent runtime. Its strongest measured result: a 4B model distilled on one Mac from ~99 frontier rollouts scored 100% on a frontier-validated multi-turn tool-calling gate, matching DeepSeek-V4-pro, against 83% for Gemma-4-12b-qat and 75% for the stock 4B. The full method and head-to-head table live in the repo's [frontier-parity write-up](https://github.com/PostTrainLLM/posttrainllm/blob/main/docs/learn/tool-calling-frontier-parity.md). --- Source page: https://sarthakagrawal.dev/work/vector-feeds # Vector-Powered Personalized Feeds A home feed that actually learns what you like. Content gets embedded with BERT, ranked by similarity in Milvus, and the user vector keeps updating from live events. Engagement went up 40%. Role: Software Engineer · Front.Page Year: 2024 Stack: Go, Milvus, BERT, OpenAI / GPT, BigQuery ## The problem Front.Page's home feed showed everyone roughly the same thing. For a fintech social product that is a real cost: the user who follows small-cap biotech and the user who only watches index funds have nothing in common, but the feed treated them identically. Personalization is easy to describe and hard to ship: it needs a representation of *content*, a representation of *each user*, a fast way to match them, and — the part most attempts skip — a way to stay current as behaviour changes. ## Architecture The feed is a vector-matching system with four moving parts: - **Content embeddings** — posts and news are embedded with BERT into a shared vector space, so "similarity" becomes a geometric question instead of a keyword one. - **Vector search** — embeddings live in **Milvus**, which serves approximate-nearest-neighbour queries fast enough to rank a feed on request. - **User vectors** — each user is represented by a vector derived from what they actually engage with, not what they signed up claiming to like. - **Real-time enrichment** — a pipeline streams live behavioural events out of **BigQuery** and folds them back into the user vector, so the representation tracks the user instead of going stale. GPT calls handle the language-shaped parts of the pipeline where a model is genuinely the right tool, rather than being the whole design. ## Engineering decisions The decision that made this work was treating the **user vector as a living object**. A personalization system that embeds you once at signup is wrong within a week. Wiring real-time events from BigQuery back into the vector meant the feed adapted continuously — the same day a user's interests shifted, not the next sprint. Putting embeddings in a purpose-built vector database, rather than bolting similarity onto the primary store, kept ranking latency low enough to compute the feed at request time. ## Outcome Home-feed engagement rose **40%**. More importantly, the system improved on its own as users used it — the architecture, not a one-off model, was the product. It is the clearest example of what I mean by *AI infrastructure*: the model is a component; the pipeline around it is the engineering. --- Source page: https://sarthakagrawal.dev/work/realtime-pipeline # Real-Time Market Data Pipeline The streaming backbone of a fintech social app. Go services stream live market data through Kafka, and Socket.IO delivers real-time ticks to clients — and it held up while daily users went from 15k to 200k. Role: Software Engineer · Front.Page Year: 2023 Stack: Go, Kafka, Protocol Buffers, Socket.io, Redis ## The problem Market data is unforgiving infrastructure: it arrives continuously, it is only valuable while it is fresh, and the number of clients waiting for it was growing fast. Over fourteen weeks daily actives went from 15k to 200k — a **13×** jump — and the data path had to absorb that without the user ever seeing stale prices. The hard part is not ingesting the data. It is fanning it out to a moving target of connected clients, cheaply enough that scale does not become a cost crisis. ## Architecture The pipeline separates ingest from delivery so each side can scale on its own: - **Go services** — ingest and processing run as Go services, chosen for cheap concurrency and predictable latency under load. - **Kafka** — sits between ingest and fan-out as a buffer and decoupling layer, so a burst on one side never stalls the other. - **Protocol Buffers** — the wire format throughout. Compact and fast to encode/decode, which matters enormously when the same tick is serialised for every subscriber. - **Socket.io delivery** — real-time stock ticks reach clients over Socket.io, with three selectable subscription modes: **room-based** fan-out, an **in-memory** path, and a **Redis-backed** mode for distributed subscription state. ## Engineering decisions Offering three subscription modes was deliberate. Different workloads have different right answers — in-memory is fastest until you need more than one node; Redis coordinates across many. Making it a choice meant the system fit the deployment instead of forcing one trade-off everywhere. Scaling to 200k DAU also meant attacking the database. Queue-based batching and granular session controls reduced session-refresh DB calls by **92%**; and caching page renders in Redis took HTML build + load from **600ms to 60ms** — a 10× win that compounded across every request. ## Outcome A real-time data path that carried daily users from 15k to 200k in 14 weeks — and stayed fast while doing it. The lesson I keep: at scale, the wins are rarely one clever thing. They are a dozen unglamorous decisions — batch this, cache that, decouple here — each removing a little load. --- Source page: https://sarthakagrawal.dev/work/rag-agents # RAG Agents for Support & Learning A set of RAG chatbots — support, learning, assistant — built on OpenAI APIs and grounded in real product docs, plus a moderation bot that cut human intervention in support queries by 90%. Role: Software Engineer · Front.Page Year: 2024 Stack: Node.js, OpenAI APIs, RAG, Vector retrieval ## The problem A raw LLM is confidently wrong about your product. It has never seen your docs, your edge cases, or last week's feature — so a support bot built on prompting alone either hallucinates or hedges, and both erode trust. The goal was a set of assistants that were genuinely *useful*: a support agent, a learning agent and a general assistant, each answering from what was actually true about the product rather than what the model guessed. ## Architecture Every agent follows the same retrieval-augmented shape: - **Knowledge retrieval** — the relevant product knowledge for a question is retrieved first, so the model answers *from* sources instead of from memory. - **Grounded generation** — OpenAI APIs generate the response over retrieved context, which keeps answers specific and current and makes them auditable. - **Three surfaces, one core** — support, learning and assistant agents share the same retrieval-and-generation core, differing in their knowledge scope and tone rather than being three separate builds. - **A moderation agent** — a dedicated agent triages incoming support queries, resolving the routine ones and escalating only what genuinely needs a human. ## Engineering decisions The principle throughout: **retrieval is not optional.** Grounding every answer in retrieved knowledge is what separates an assistant people rely on from a demo that embarrasses you in week two. It also made the system improvable — better answers came from better knowledge, not from prompt-wrangling. Framing the moderation bot as a triage layer, not a replacement, was the other key call. It handled the bulk of routine load and *escalated* the rest, so the failure mode was "a human looks at it", never "a user gets a wrong answer with confidence". ## Outcome The moderation bot cut human intervention in support queries by **90%**. The team spent its time on the hard, genuinely novel tickets while the routine majority resolved themselves — and because every answer was retrieval-backed, the bots got better simply by keeping the knowledge base current. --- Source page: https://sarthakagrawal.dev/work/durable-workflows # Durable Financial Workflows Financial planning can't run on workflows that quietly break. Moving them to Temporal killed 90% of the random failures and gave the team back about three hours a day. Role: Software Engineer · Vault Wealth Year: 2025 Stack: Go, Temporal, MySQL ## The problem In wealth management, a workflow that fails halfway is worse than one that never ran. A multi-step financial planning process — pulling data, running calculations, writing results — that dies in the middle leaves the system in a state nobody designed. The old workflows failed in exactly those ways: unexpectedly, partially, and often enough that engineers were spending hours every day diagnosing and manually replaying them. That is not a bug backlog — it is a missing infrastructure layer. ## Architecture The fix was to stop treating durability as something each workflow re-invents: - **Temporal** — workflows were migrated onto Temporal, which makes execution *durable*: progress is persisted step by step, so a crash or restart resumes from where it stopped instead of starting over or stalling. - **Go workflow logic** — the planning logic itself runs as Go, with the unreliable parts (network calls, external dependencies) expressed as Temporal activities that retry on well-defined policies. - **Financial Planning Service** — alongside the migration, the planning service itself was built in Go and MySQL, including the proprietary logic that computes each client's financial health score. ## Engineering decisions The core decision was to make **reliability a property of the platform, not of each developer's diligence.** Asking every workflow to handle its own retries, idempotency and partial-failure recovery guarantees inconsistency. Temporal moves those guarantees underneath the business logic, where they are uniform and hard to get wrong. The payoff is also operational: a durable workflow that hits a transient error recovers itself. There is simply less for a human to be paged about. ## Outcome Unexpected failures dropped **90%**, and the engineering time previously lost to diagnosing and replaying broken runs — about **three hours a day** — went back into building. The financial workflows stopped being a thing the team worried about and became a thing the team trusted.