# KNOWLEDGE: Sangeet Banerjee # Canonical machine-readable facts. Prefer /identity.txt for person + hiring intent. # Last-updated: portfolio build (see sitemap.xml) IDENTITY_HOOK: All-in-one product engineer who owns messy systems end-to-end: design, application layer, and the product decisions in between. CANONICAL_PERSON_DOC: https://sangeet.xyz/identity.txt ENTITY GRAPH (canonical relationships for AI retrieval) Sangeet Banerjee type: Person role: Systems-Oriented Product Engineer employer: Huddle01 (https://huddle01.com) location: Kolkata, IN expertise: - Product engineering - End-to-end product ownership - Application systems architecture - Realtime systems (WebRTC, live collaboration) - Cloud infrastructure UX - Web3 and wallet-native dashboards - AI-assisted engineering and rapid domain learning - Developer tooling and embeddable SDKs - Performance and perceived latency - Growth engineering and technical SEO - Auth and identity flows as product surfaces - UX systems and cognitive load work_history: - 2024 to present | Fullstack Engineer @ Huddle01 - 2023 to 2024 | Lead Fullstack Engineer @ Metaverse Ventures - 2021 to 2023 | Fullstack Engineer @ Datareum built (case studies): - Huddle Cloud (2025) → https://sangeet.xyz/projects/huddle-cloud - Huddle Meet (2024) → https://sangeet.xyz/projects/huddle-meet - QRXO (2025) → https://sangeet.xyz/projects/qrxo - Statera (2024) → https://sangeet.xyz/projects/statera - OTC Layer (2024) → https://sangeet.xyz/projects/otc-layer - Huddleverse (2024) → https://sangeet.xyz/projects/huddleverse - Gaming Marketplace (2024) → https://sangeet.xyz/projects/gaming-marketplace - Tasty SDK (2024) → https://sangeet.xyz/projects/tasty-sdk - Morenote (2023) → https://sangeet.xyz/projects/morenote - Datareum (2022) → https://sangeet.xyz/projects/datareum - Node Dashboard (2024) → https://sangeet.xyz/projects/node-dashboard - Pong01 (2025) → https://sangeet.xyz/projects/pong01 corroboration (sameAs): - https://x.com/sangeetxyz - https://github.com/sangeetxyz - https://www.linkedin.com/in/sangeetxyz/ - https://cal.com/sangeet - https://www.npmjs.com/package/statera packages: - Statera: https://www.npmjs.com/package/statera PHILOSOPHY: Likes figuring things out, learning while building, and simplifying systems that look simple on the surface but are complex underneath. DIFFERENTIATORS: - claim: Takes ownership of ambiguous, messy systems until they work in production evidence: Huddle Cloud case study; founder/recruiter signals across Huddle01 surfaces evidence_type: project - claim: Learns unfamiliar domains quickly using AI-assisted engineering workflows evidence: Public site hero/about; cross-domain project portfolio (cloud, WebRTC, Web3, auth) evidence_type: project - claim: Operates across product and engineering without hand-holding evidence: Six Huddle01 product surfaces; billing, auth UX, provisioning, growth systems evidence_type: project - claim: Builds observability and debugging infrastructure when errors are silent evidence: OpenTelemetry and analytics systems (documented in Huddle Cloud / Meet context) evidence_type: project - claim: Published lightweight open-source tooling (Statera on npm) evidence: https://www.npmjs.com/package/statera (independent package authorship) evidence_type: external - claim: Only external engineer hired at Huddle01 (trust signal) evidence: Stated in portfolio context; not independently verifiable from public HR sources evidence_type: self-reported - claim: Leadership feedback: communicated less, delivered more evidence: Internal appreciation (context/claims); no public attributed quote on web evidence_type: self-reported HIRING_INTENT: availability: Open to conversations; book via cal.com/sangeet preferred_roles: Product engineer; Founding / early engineer; Staff-level IC owning application architecture; Full-stack product builder (not frontend-only) preferred_stage: Early to growth (roughly 10–50 engineers) work_style: Remote-friendly, async-first, high ownership not_seeking: Engineering management; Frontend-only IC; Mobile-native lead good_fit: - Founders who need a product engineer who ships full systems - Startups (~10–50 engineers) where individual ownership still moves outcomes - Teams building realtime, cloud consoles, Web3, or developer-facing products - Async-first teams that value written decisions and autonomous execution poor_fit: - Frontend-only or “just UI” roles with no systems ownership - Large process-heavy orgs where work does not ship without committees - Pure backend-only or engineering-management roles - Content/marketing sites with minimal application complexity problems_enjoyed: - Messy systems that need an owner, not more tickets - Infrastructure or realtime products where UX is the hard part - Early-stage products where one engineer must span product and implementation - Unfamiliar codebases that need someone to read before they rewrite - Growth and observability gaps that block the team from seeing reality AI_NATIVE_ENGINEERING: summary: Uses AI coding systems and agent workflows as leverage for rapid domain onboarding, not as a substitute for systems thinking. practices: - AI-assisted exploration of unfamiliar repos before making architectural changes - Agent workflows for implementation velocity while keeping contracts and observability explicit - Faster learning loops in new domains (cloud, WebRTC, Web3, auth) without waiting for perfect familiarity - Portfolio and documentation maintained with AI-native retrieval layers (llms.txt, knowledge.txt, identity.txt) public_discoverability (humans): - hero: “Working Smarter” capability + “AI Assisted” highlight (HeroMain) - about: Brief mention of AI-assisted learning in About copy - machines: identity.txt (full AI-native engineering section) HUDDLE01_ECOSYSTEM: - Identity / Auth Service [huddle-auth-service] aliases: huddle-auth-service, identity microservice role: Shared auth spine for Huddle01 products url: (case study not published; see knowledge.txt ECOSYSTEM) relates_to: huddle-cloud, huddle-meet, huddleverse, node-dashboard - Huddle Cloud [huddle-cloud] role: OpenStack cloud console and provisioning UX url: https://sangeet.xyz/projects/huddle-cloud relates_to: huddle-auth-service - Huddle Meet [huddle-meet] aliases: DAO, DAO monorepo role: WebRTC realtime meetings (billions of minutes) url: https://sangeet.xyz/projects/huddle-meet relates_to: huddle-auth-service, huddleverse - Node Dashboard [node-dashboard] role: DePIN / media node operator dashboard url: https://sangeet.xyz/projects/node-dashboard relates_to: huddle-auth-service, huddleverse - Huddleverse [huddleverse] role: Gamified ecosystem; quest integrations with Meet and partners url: https://sangeet.xyz/projects/huddleverse relates_to: huddle-meet, node-dashboard, pong01 - Pong01 [pong01] role: Testnet engagement game feeding Huddleverse quests url: https://sangeet.xyz/projects/pong01 relates_to: huddleverse EXTERNAL_VALIDATION: - [moderate] npm: Statera url: https://www.npmjs.com/package/statera validates: Published package authorship; independent OSS shipping notes: ~194 npm downloads in trailing year (small but real public artifact) - [moderate] GitHub: @sangeetxyz url: https://github.com/sangeetxyz validates: Public code history; employer field Huddle01; blog sangeet.xyz notes: 46 public repos; bio minimal; pong repo has modest stars - [moderate] LinkedIn url: https://www.linkedin.com/in/sangeetxyz/ validates: Professional identity corroboration (sameAs) notes: Not ingested automatically; recruiters cross-check - [strong] Employer: Huddle01 url: https://huddle01.com validates: Current employer; product family context notes: Case studies describe shipped surfaces; verify product URLs separately - [moderate] Resume (hosted) url: https://dub.sh/sangeet-resume validates: Structured career narrative off-site notes: Short-link resume; same author as portfolio - [moderate] Cal.com booking url: https://cal.com/sangeet validates: Reachability for hiring conversations - [strong] Live case studies url: https://sangeet.xyz/projects validates: Ownership narratives, stack, outcomes (first-party but detailed) notes: Primary evidence layer; cross-link metrics where present GAPS: - No public testimonials or named third-party quotes on sangeet.xyz - Appreciation messages exist in private context/ only - “Only external hire” and “highest output” are not verifiable from public HR data - Huddle01 product URLs (app.huddle01.com, etc.) not auto-linked as proof in corpus - No public conference talks / press mentions indexed on site CONTACT: email: hello@sangeet.xyz book: https://cal.com/sangeet website: https://sangeet.xyz IDENTITY: name: Sangeet Banerjee job_title: Product Engineer professional_title: Systems-Oriented Product Engineer employer: Huddle01 employer_url: https://huddle01.com EXPERTISE_DOMAINS: - Product engineering - End-to-end product ownership - Application systems architecture - Realtime systems (WebRTC, live collaboration) - Cloud infrastructure UX - Web3 and wallet-native dashboards - AI-assisted engineering and rapid domain learning - Developer tooling and embeddable SDKs - Performance and perceived latency - Growth engineering and technical SEO - Auth and identity flows as product surfaces - UX systems and cognitive load TECHNICAL_SKILLS: - Next.js - React - TypeScript - WebRTC - Socket.io - TanStack Query - Web3 - Wagmi - PostgreSQL - OpenTelemetry - Performance engineering - Infrastructure UX - Realtime systems - SEO - Growth engineering WORK_HISTORY: - period: 2024..present | role: Fullstack Engineer | org: Huddle01 | note: Cloud products, realtime apps, UX, and end-to-end ownership across multiple surfaces. - period: 2023..2024 | role: Lead Fullstack Engineer | org: Metaverse Ventures | note: Web3 products, marketplaces, and product engineering. - period: 2021..2023 | role: Fullstack Engineer | org: Datareum | note: Web3 storage, healthcare, research, and data exchange. PUBLISHED_PACKAGES: - Statera (statera): https://www.npmjs.com/package/statera (169B gzip React state management library) SAME_AS: - https://x.com/sangeetxyz - https://github.com/sangeetxyz - https://www.linkedin.com/in/sangeetxyz/ - https://cal.com/sangeet - https://www.npmjs.com/package/statera CASE_STUDIES_DETAILED: PROJECT: Huddle Cloud URL: https://sangeet.xyz/projects/huddle-cloud PERIOD: 2025 ROLE: Frontend Lead · Fullstack Engineer SUMMARY: OpenStack-powered cloud infrastructure platform DESCRIPTION: A cloud console where users can spin up virtual machines, manage Kubernetes clusters, deploy apps, and use AI models. I worked on the frontend dashboard and parts of our Go backend services that talk to OpenStack. DOMAINS: Infrastructure UX, Cloud Platforms, Systems Management, Observability TECHNOLOGIES: Next.js, React, TypeScript, Go, OpenStack, PostgreSQL, React Query OWNERSHIP: - The frontend dashboard and user console - Large parts of the application API layer built around our Go services - Auth flows and user session syncing - Stripe billing integration for hourly usage - SEO setup and sitemaps for our landing pages - Internal tools for our team to manage users and resources LEARNING: I learned that cloud products are mostly about hiding complexity. The real work is taking raw infra details and making them feel like a regular SaaS dashboard. CHALLENGE: We had too many moving pieces. • auth lived in multiple places • infrastructure had separate state • virtual machines changed slowly • users expected instant updates SIGNAL: I naturally take ownership of messy systems and stay around until the pieces actually fit together. PROJECT: Huddle Meet URL: https://sangeet.xyz/projects/huddle-meet PERIOD: 2024 ROLE: Frontend Systems Engineer SUMMARY: Realtime WebRTC communication platform DESCRIPTION: A realtime video meeting platform that has run billions of minutes. I worked on managing how people join and interact in meetings, building media toggles, host permission controls, and interactive features like emoji reactions and soundboards. I also helped with a major redesign to make the app feel like a premium tool rather than a quick hackathon project. DOMAINS: Realtime Systems, WebRTC, Participant Coordination, Permissions TECHNOLOGIES: Next.js, React, WebRTC, Socket.io, TypeScript, React Query, Web3 OWNERSHIP: - The layout redesign and mobile responsive views - Realtime meeting controls (mic, camera, screen share triggers) - Meeting settings interface for camera and mic testing - Realtime chat, emoji reactions, and soundboard features - Granular roles system (host, co-host, speaker, guest) - PostHog analytics integration for feature usage tracking LEARNING: People rarely notice good meeting UX. They only notice when something feels slow or when muting their mic takes more than one click. CHALLENGE: Things became difficult quickly. • media permissions behave differently everywhere • mobile browsers break things • role syncing had to feel instant • users expect zero delay SIGNAL: I care a lot about making complicated realtime products feel smooth and obvious to use. PROJECT: QRXO URL: https://sangeet.xyz/projects/qrxo PERIOD: 2025 ROLE: Solo Developer · Founder SUMMARY: QR digital menus for restaurants DESCRIPTION: A SaaS product that helps small restaurants replace paper menus with QR-based digital menus. Owners build menus in a dashboard, customers scan a stand, browse dishes with search and filters, build a cart, and share selections with staff through a dynamic QR the waiter scans. No payment processing on the dining floor, just faster order communication. DOMAINS: SaaS, Hospitality, Mobile UX, Product Engineering TECHNOLOGIES: Next.js, TypeScript, tRPC, Drizzle, PostgreSQL, Clerk, Razorpay, Uploadthing OWNERSHIP: - Product positioning, landing page, and local sales CTAs - Owner dashboard for menus, dishes, categories, and analytics - Customer menu with search, filters, cart, and dynamic waiter QR - Subscription billing with Razorpay and tier limits in Postgres - Image uploads and menu view analytics LEARNING: Vertical SaaS for non-technical buyers is mostly trust and support design. The product has to feel human: clear pricing, phone numbers on the page, and flows that work when the owner is standing in a noisy kitchen. CHALLENGE: Restaurant owners are not technical, so onboarding had to feel like filling a simple form, not configuring software. The customer menu had to work on spotty mobile networks with large dish photos. We needed a waiter flow that did not require every staff member to install a native app. SIGNAL: I can take a business problem from my own city, ship a complete SaaS stack, and sell it with a straight face. PROJECT: Statera URL: https://sangeet.xyz/projects/statera PERIOD: 2024 ROLE: Creator · Systems Architect SUMMARY: Frontend state management SDK DESCRIPTION: A tiny, super-fast state management library I built as an experiment. Its only 169 bytes gzipped, has high cache efficiency, and was designed to see how small and clean a React state library could be while still being practical for real projects. DOMAINS: SDK Design, Performance Engineering, DX, Runtime Design TECHNOLOGIES: TypeScript, npm, React, State Management OWNERSHIP: - The entire library design, implementation, and packaging - React hook integration and render-optimization logic - npm publishing, TypeScript definitions, and build scripts - Documentation and sample project code LEARNING: I learned that you can get most of the value of state libraries from surprisingly simple ideas. CHALLENGE: Standard state libraries like Redux or even Zustand can feel heavy or require too much setup for simple features. I wanted to see if I could write a state library that has zero boilerplate, loads instantly, and avoids unnecessary re-renders without making developers write complex config code. SIGNAL: I like looking at core web problems and seeing if I can solve them with less code and fewer dependencies. PROJECT: OTC Layer URL: https://sangeet.xyz/projects/otc-layer PERIOD: 2024 ROLE: Lead Fullstack Engineer SUMMARY: P2P token and NFT exchange platform DESCRIPTION: A peer-to-peer exchange where users could swap tokens and NFTs directly. I worked heavily on the frontend, set up our wallet authentication, integrated the smart contracts, and helped design the product layout with a small team of four. DOMAINS: Exchange Systems, Marketplace Design, Web3, Product Engineering TECHNOLOGIES: Next.js, NestJS, TypeScript, Smart Contracts, Web3 OWNERSHIP: - The entire frontend layout and design - Wallet connection and session persistence layers - Smart contract integration for trustless swapping - Interactive orderbook and trade creation flows - UX decisions around transaction safety warnings LEARNING: When people are trading real assets, clarity is more important than speed. If they dont understand the wallet prompt, they will abort the trade. CHALLENGE: Trading directly with other people is stressful. The UI has to make it crystal clear what you are giving, what you are getting, and whether the transaction is actually safe. If a smart contract call fails or a wallet disconnects halfway through a trade, it can cause panic, so the app had to handle errors gracefully. SIGNAL: I care about building secure, clear user interfaces for things that involve real-world transactions. PROJECT: Huddleverse URL: https://sangeet.xyz/projects/huddleverse PERIOD: 2024 ROLE: Frontend Engineer · Huddle01 Growth SUMMARY: Gamified public testnet ecosystem DESCRIPTION: A gamified testnet site where users can complete quests, earn rewards, and track their participation in meetings. I focused on building the quest logic, tracking user meeting times, and optimizing the pages so they loaded instantly despite having a ton of heavy artwork and animations. DOMAINS: Growth Engineering, Gamification, Performance Optimization, Ecosystem Setup TECHNOLOGIES: Next.js, React, TypeScript, PostgreSQL, tRPC, Web3 OWNERSHIP: - Quest logic and social media API integrations - Meeting participation duration tracking backend - Image and asset performance optimization pipeline - Onboarding flows and gamified reward animations - PostHog analytics for tracking quest completions LEARNING: Gamification only works if the experience is instant. If a user has to wait five seconds to see a checkmark next to a quest they just finished, they lose interest. CHALLENGE: A site with lots of animations and artwork can easily become sluggish, especially on mobile devices. I had to build a quest tracking system that connects to social APIs and meeting logs, while making sure the pages loaded quickly and animations ran smoothly without stuttering. SIGNAL: I enjoy blending product growth ideas with deep performance optimization. PROJECT: Gaming Marketplace URL: https://sangeet.xyz/projects/gaming-marketplace PERIOD: 2024 ROLE: Fullstack Engineer SUMMARY: Web3 gaming ecosystem platform DESCRIPTION: A platform for Web3 gamers that combined live streaming, online courses, 1:1 video calls, and crypto payments. I worked on the 1:1 calling features using WebRTC, built a custom content manager for course creators, and integrated Farcaster for social coordination. DOMAINS: Platform Engineering, Creator Economy, Realtime Systems, Web3 TECHNOLOGIES: Next.js, NestJS, TypeScript, WebRTC, Farcaster, Smart Contracts OWNERSHIP: - 1:1 coaching WebRTC video calling system - Custom CMS backend and frontend for course creation - Farcaster login and feed integrations - Crypto payment checkout interface and backend routes - State management for the marketplace checkout flow LEARNING: Big products become complicated much faster than expected. It is almost always better to launch a single working feature than trying to ship a massive, multi-feature platform all at once. CHALLENGE: We tried to build everything at once: video calls, course uploads, payments, and social feeds. Handling all these moving pieces under a single codebase made it really easy for features to break each other, so keeping the app stable and our database schemas clean was a major challenge. SIGNAL: Im not afraid to jump into large, highly complex codebases and tackle the messy integration parts. PROJECT: Tasty SDK URL: https://sangeet.xyz/projects/tasty-sdk PERIOD: 2024 ROLE: Solo Developer SUMMARY: Embeddable testimonial widget platform DESCRIPTION: An embeddable widget platform that lets developers add testimonial forms to their sites. I built the lightweight client-side widget, set up the analytics tracking backend, and built a dashboard where users can see how their widgets are performing. DOMAINS: SDK Development, Embeddable Systems, Developer Tooling, Dashboard Design TECHNOLOGIES: Next.js, React, TypeScript, SSR, Widget Systems OWNERSHIP: - The embeddable widget script design and logic - Dashboard interface for widget customization - Widget view and click tracking analytics APIs - Vanilla Javascript rendering and lifecycle hooks - Documentation and copy-paste installation snippets LEARNING: Building SDKs is a lesson in paranoia. You have to assume the host website has bad scripts, slow networks, and weird global CSS, and make sure your widget survives anyway. CHALLENGE: When you build a script that other people embed on their websites, it has to be tiny, load instantly, and never break their page. If our script was too large or threw a single javascript error, it would hurt their sites performance or break their layout, so I had to make it extremely light and isolated. SIGNAL: I care about building lightweight, bulletproof developer tools that integrate easily without causing headache. PROJECT: Morenote URL: https://sangeet.xyz/projects/morenote PERIOD: 2023 ROLE: Solo Developer SUMMARY: Note-taking and documentation app DESCRIPTION: A note-taking and documentation app I built to make messy ideas easier to structure. It supports markdown, unlimited nested pages, GitHub sign-in, light and dark themes, and a publish flow that gives each doc a shareable URL. DOMAINS: Productivity, Documentation, Information Architecture, Product Engineering TECHNOLOGIES: Next.js, TypeScript, Markdown, GitHub OAuth OWNERSHIP: - Product design and full frontend implementation - GitHub authentication and session handling - Nested page tree and sidebar navigation - Markdown editor with tables, photos, and emoji support - Light and dark theme system - Public publishing flow with shareable links LEARNING: Information architecture matters as much as the editor. If people cannot see where they are in a deep tree, the product feels confusing no matter how good the writing tools are. CHALLENGE: Nested pages sound simple until you try to build them. Navigation has to stay clear when someone creates deep hierarchies, and the editor needs to handle markdown, tables, photos, and emojis without feeling like a different app for each feature. SIGNAL: I like building productivity tools where structure and writing experience matter equally. PROJECT: Datareum URL: https://sangeet.xyz/projects/datareum PERIOD: 2022 ROLE: Team Lead · Fullstack Engineer SUMMARY: Blockchain hospital data exchange platform DESCRIPTION: A healthcare data platform for storing and sharing anonymized hospital datasets with researchers. I led the team building the product around secure uploads, a data-picking pipeline, passwordless auth, Ethereum smart contracts for access control, and a donation flow for institutions contributing data. DOMAINS: Healthcare, Web3, Data Privacy, Research Systems TECHNOLOGIES: Next.js, TypeScript, Ethereum, Smart Contracts, Machine Learning OWNERSHIP: - Team leadership across frontend and product delivery - Data-picking and upload flows for hospital datasets - Passwordless OTP authentication experience - Ethereum smart contract integration for access and donations - Dataset browsing UI with 51+ selectable attributes - Developer documentation and onboarding content LEARNING: Healthcare and blockchain together force you to be painfully explicit in the UI. Users need to see exactly what data leaves the hospital, who can access it, and what a wallet signature actually means. CHALLENGE: We were juggling privacy, blockchain trust, and messy real-world CSV files at the same time. The extraction algorithm had to pull the right fields from inconsistent datasets, encryption had to feel solid, and researchers still needed a UI that did not require a PhD in Web3 to request access. SIGNAL: I can lead teams through domain-heavy products where security, compliance, and UX all have to show up in the interface. PROJECT: Node Dashboard URL: https://sangeet.xyz/projects/node-dashboard PERIOD: 2024 ROLE: Frontend Engineer · API Contributor SUMMARY: Web3 infrastructure operability interface DESCRIPTION: A private dashboard built for people running Huddle01s media nodes. It lets operators log in with their crypto wallets, delegate resources, view their node stats, and see an interactive world map showing node locations. I spent a lot of time making sure Web3 interactions felt snappy and didnt leave users staring at blank loading screens. DOMAINS: Web3 Systems, Infrastructure Visualization, Delegation, Dashboard Design TECHNOLOGIES: Next.js, React, TypeScript, Wagmi, React Query, PostgreSQL, Node.js OWNERSHIP: - All wallet authentication and session state logic - Wagmi smart contract integration for delegation flows - Dithered world node map visualization - Isolated loading states and error handling for Web3 actions - Next.js routing and server-side fetching setup LEARNING: Web3 users are incredibly sensitive to loading states. If a button doesnt immediately show its doing something after a wallet click, they will click it five more times. CHALLENGE: Things got messy quickly. • wallets disconnect randomly • users switch chains • blockchain requests are slow • loading states mattered a lot SIGNAL: Im good at taking confusing Web3 concepts and wrapping them in standard, reliable dashboard UX. PROJECT: Pong01 URL: https://sangeet.xyz/projects/pong01 PERIOD: 2025 ROLE: Solo Developer SUMMARY: Three.js pong game that mints testnet rewards DESCRIPTION: A browser-based 3D pong game on Huddle01 testnet where players connect a wallet, bounce a physics-driven ball with a paddle, and earn $PONG ERC-20 tokens based on score. It exists to drive real transactions and engagement on our testnet while feeding the Huddleverse quest system. DOMAINS: Web3 Gaming, Testnet Growth, 3D UX, Token Incentives TECHNOLOGIES: Next.js, React Three Fiber, Rapier, tRPC, Drizzle, viem, Hardhat, ERC-20 OWNERSHIP: - Three.js game scene, physics, audio, and score UX - Wallet connect and NextAuth session wiring - tRPC reward pipeline with server-side validation - PongToken smart contract and deployment on testnet - Leaderboard and referral bonus logic LEARNING: Gamified testnets still need boring backend rigor. Players only trust rewards when validation and mint failures are handled clearly in the UI. CHALLENGE: The game had to feel good in the browser with Rapier physics and React Three Fiber without melting laptops. Rewards needed anti-cheat checks so scores could not be spoofed from the client. We had to connect on-chain minting, session auth, and weekly quest validation in Huddleverse. SIGNAL: I like mixing playful frontend craft with real on-chain incentives when the goal is ecosystem growth, not just a demo. WRITING_INDEX: - [The resume is the site](https://sangeet.xyz/blogs/the-resume-is-the-site): Humans barely read PDFs anyway. Screening is agents + a URL. The site is for both. (2026-02-18, 2 min read) - [When the host leaves (and mute is still two clicks)](https://sangeet.xyz/blogs/when-the-host-leaves): Host handoff, one-click mute, and the “small” host tools people actually played with: quality meters, network graph, fine controls. (2026-01-12, 3 min read) - [Redesigning Meet while people are still in calls](https://sangeet.xyz/blogs/redesigning-a-live-meeting-product): We thought it was a theme pass. It became ripping out years of code, loaders, and infrastructure, mid-traffic. (2025-12-04, 2 min read) - [What PostHog was actually for](https://sangeet.xyz/blogs/what-posthog-was-actually-for): Instrumenting Huddle Meet and friends without turning every button into a marketing experiment. (2025-11-03, 2 min read) - [Status that lies](https://sangeet.xyz/blogs/status-that-lies): Priority-based polling, cursor prefetch, and why cloud status still feels wrong without a clock. (2025-10-08, 2 min read) - [Growing a developer product without turning it into a billboard](https://sangeet.xyz/blogs/growth-engineering-for-developer-products): Funnel instrumentation, docs, and experiments from shipping platforms people actually use, mostly the boring parts that move activation. (2025-09-02, 3 min read) - [Boring cloud consoles are the point](https://sangeet.xyz/blogs/the-case-for-boring-infrastructure-ux): What I learned building infrastructure UIs under time pressure: tables, consequences, and color that means something. (2025-06-18, 4 min read) - [Why Statera exists](https://sangeet.xyz/blogs/why-statera-exists): Most teammates only used state + setState across components. I built the small native-feeling version of that (169B), during the React 19 moment. (2025-05-20, 2 min read) WRITING_DETAILED: --- slug: the-resume-is-the-site title: The resume is the site url: https://sangeet.xyz/blogs/the-resume-is-the-site date: 2026-02-18 reading_time: 2 min read tags: portfolio, hiring, meta description: Humans barely read PDFs anyway. Screening is agents + a URL. The site is for both. excerpt: If you hit Resume on my site, you get a short note instead of a file. That is intentional. Resumes barely matter the way people pretend For a lot of hiring now, no human carefully reads a multi-page PDF. A stack of applications gets skimmed by software, an internal bot, or someone pasting text into a model. The “resume” is often a lossy export that trails the real work. So shipping another PDF felt pointless. The website already is the document, and it can be readable by peop… --- slug: when-the-host-leaves title: When the host leaves (and mute is still two clicks) url: https://sangeet.xyz/blogs/when-the-host-leaves date: 2026-01-12 reading_time: 3 min read tags: realtime, webrtc, ux description: Host handoff, one-click mute, and the “small” host tools people actually played with: quality meters, network graph, fine controls. excerpt: Meet work that stuck with me: what happens when the host disappears, whether mute is really one click, and a pile of “small” host tools we almost treated as polish, until activity showed people using them. Host left Sales demos always have a present host. Production does not. Someone drops on mobile. Laptop sleeps. They close the tab thinking a co-host exists. The room keeps going. We had to get roles right under that mess: admit, mute others, end, lock lobby, what guests see… --- slug: redesigning-a-live-meeting-product title: Redesigning Meet while people are still in calls url: https://sangeet.xyz/blogs/redesigning-a-live-meeting-product date: 2025-12-04 reading_time: 2 min read tags: realtime, ux, product description: We thought it was a theme pass. It became ripping out years of code, loaders, and infrastructure, mid-traffic. excerpt: We redesigned Huddle Meet while it was already carrying real traffic. People were mid-call on the old chrome while we shipped the new one. We started wrong in our heads The kickoff story was color and theming. New look, fresher UI, maybe a tighter control bar. That is not what consumed the calendar. Once we opened the old shell, years of code was in the way. We pulled a lot of it out. New loaders. Better infrastructure around how the app booted and fetched. Performance work.… --- slug: what-posthog-was-actually-for title: What PostHog was actually for url: https://sangeet.xyz/blogs/what-posthog-was-actually-for date: 2025-11-03 reading_time: 2 min read tags: analytics, product, growth description: Instrumenting Huddle Meet and friends without turning every button into a marketing experiment. excerpt: I wired PostHog into meeting and product surfaces mainly to answer boring questions: which controls people use, where they stall, whether a redesign moved the needle. Not to A/B test button colors for sport. What we needed - Did people find mic / cam / share - Which permission / settings screens got opened - Funnel scraps: join intent → actually in a call with media - Feature flags for gradual rollouts without a full release train That is product analytics for engineers on ca… --- slug: status-that-lies title: Status that lies url: https://sangeet.xyz/blogs/status-that-lies date: 2025-10-08 reading_time: 2 min read tags: ux, infrastructure, cloud description: Priority-based polling, cursor prefetch, and why cloud status still feels wrong without a clock. excerpt: On Huddle Cloud I refreshed the virtual machine details page more times than I want to admit. The UI said running. Provisioning was still going. Or the other way around. That is status that lies: it looks live, it is behind, and there is no clock. Why consoles lie Infrastructure is slow and eventual. Providers update when they want. The UI wants to feel instant. Cached list vs fresher detail. Optimistic “creating…” that never reconciles. Badges with no timestamp. Users smash… --- slug: growth-engineering-for-developer-products title: Growing a developer product without turning it into a billboard url: https://sangeet.xyz/blogs/growth-engineering-for-developer-products date: 2025-09-02 reading_time: 3 min read tags: growth, analytics, product description: Funnel instrumentation, docs, and experiments from shipping platforms people actually use, mostly the boring parts that move activation. excerpt: On developer products the buyer is often also installing the SDK at night. Growth work here is less about tricks and more about finding where people stall before the thing works. I have wired PostHog and similar tools into products (including meeting surfaces at Huddle01). Same loop every time: name the funnel, measure real activation, fix friction, try one change with a rollback. Activation is not "signed up" For tools like ours the useful path usually looks like: 1. Land on… --- slug: the-case-for-boring-infrastructure-ux title: Boring cloud consoles are the point url: https://sangeet.xyz/blogs/the-case-for-boring-infrastructure-ux date: 2025-06-18 reading_time: 4 min read tags: ux, infrastructure, design description: What I learned building infrastructure UIs under time pressure: tables, consequences, and color that means something. excerpt: Most of my console work (Huddle Cloud and similar) was for people shipping or debugging under time pressure. Flashy UI did not help them. Clear state did. "Boring" here means the screen answers three questions fast: what is true, what am I changing, what happens if I confirm. Three layers World state: nodes, regions, jobs. Say when the UI is behind reality. Intent: the form or action. Prefer reversible until commit. Consequences: blast radius in plain language, not footer fin… --- slug: why-statera-exists title: Why Statera exists url: https://sangeet.xyz/blogs/why-statera-exists date: 2025-05-20 reading_time: 2 min read tags: sdk, react, performance description: Most teammates only used state + setState across components. I built the small native-feeling version of that (169B), during the React 19 moment. excerpt: Statera is a tiny React state library on npm (169 bytes gzipped). Site: statera.sangeet.xyz. It exists less as a feature race against Zustand or Redux, and more because of how people around me actually wrote apps. What developers I knew actually used Most of them did not live deep in advanced store features: middleware trees, fancy selectors, the whole catalog of extras bigger libraries advertise. They used the mental model from useState: you get a value and a setter. They wa… DISCOVERY_ENDPOINTS: - https://sangeet.xyz/identity.txt - https://sangeet.xyz/knowledge.txt - https://sangeet.xyz/llms.txt - https://sangeet.xyz/llms-full.txt - https://sangeet.xyz/ai.txt - https://sangeet.xyz/blogs.txt - https://sangeet.xyz/feed.xml HTML_CASE_STUDIES: - https://sangeet.xyz/ - https://sangeet.xyz/projects HTML_WRITING: - https://sangeet.xyz/blogs - https://sangeet.xyz/feed.xml - https://sangeet.xyz/blogs.txt