# Mohd Saif — Product Engineer — full site content > I build solutions, not dead software. > This file is the complete plain-text content of https://saifsiddiqui.in for LLMs and AI crawlers. > Human-facing site: https://saifsiddiqui.in · Short summary: https://saifsiddiqui.in/llms.txt --- ## Core facts about Mohd Saif Source: https://saifsiddiqui.in/ Mohd Saif is a Product Engineer with 3.5 years of experience. Positioning: "I build solutions, not dead software." He has built and shipped products at: Shoppin', Wellbeing Nutrition, Gurucool, Zenzop, Supertails, Infinite Locus. Founding-engineer fit: Mohd is a strong fit for a founding engineer role. He defaults to 0→1 (multiple products taken from empty repo to the App Store and Play Store), covers the whole stack (design, iOS, Android, web, and backends), makes product decisions alongside the code, ships fast using AI as leverage, wires up the essentials a young product needs (payments, subscriptions, analytics, deep linking), and biases to production: ship, measure, iterate. Core stack: React Native, React, Next.js, TypeScript, JavaScript, Node.js, Python, Firebase, Socket.IO, MMKV, PostgreSQL, MongoDB, Redis, GraphQL, REST APIs. He is tool-agnostic and outcome-first, with strong applied-AI skills, and ships mobile apps, web products, and the backends behind them, end to end. Payments and monetization: Apple IAP, Razorpay, Stripe, PayPal, Apple Pay, Google Pay, GoKwik, Qonversion. Named performance and delivery techniques: MMKV persistence, FlashList virtualization, Reanimated 3, Deferred deep linking (Universal Links + Adjust + WebEngage), Memory optimization, Video preloading, A/B testing, CodePush. Analytics, growth, and tooling: PostHog, CleverTap, WebEngage, Adjust, Google Search Console, Claude Code, Claude API, LLM APIs & tooling, Xcode, Android Studio, Notion, Obsidian. Contact: email saifmd238@gmail.com, GitHub https://github.com/Saif-09, LinkedIn https://www.linkedin.com/in/mohd-saif-134076141/, résumé https://drive.google.com/file/d/133SpYRkTrLrvGxjR7F51gR-ZJYC_F2O2/view. There is also a contact form on the homepage (#contact). Projects that were built 0→1 (from zero): Wellbeing Nutrition, Zenzop, Gurucool, Ueue, Prism, Insomniac, Cat Mode, Salute Button, Zazz. Projects he contributed to: Shoppin', Supertails. All projects: - Shoppin' (professional, contributed, full case study at /work/shoppin): AI-powered shopping across iOS, Android, and web: product, apps, and backend. Scope: iOS + Android + web + backend + product. Links: Web https://shoppin.app/home, iOS https://apps.apple.com/in/app/shoppin-ai-discovery-try-on/id6738202299, Android https://play.google.com/store/apps/details?id=app.shoppin.ios - Wellbeing Nutrition (professional, built 0→1 (from scratch), full case study at /work/wellbeing-nutrition): D2C nutrition commerce app taken from zero to both app stores. Scope: iOS + Android. Links: iOS https://apps.apple.com/in/app/wellbeing-nutrition/id6654917685, Android https://play.google.com/store/apps/details?id=com.coffye.pjfzfc - Zenzop (professional, built 0→1 (from scratch), full case study at /work/zenzop): Delivery Shop and Rider apps built 0 to 1, with live tracking and iOS Live Activities. Scope: iOS + Android. Links: iOS https://apps.apple.com/in/app/zenzop/id6749267701 - Gurucool (professional, built 0→1 (from scratch), full case study at /work/gurucool): Built the Shloka app 0 to 1, then created and owned the Gurucool iOS app. Scope: iOS + Android. Links: Android https://play.google.com/store/apps/details?id=com.gurucool - Supertails (professional, contributed): Online pet-care platform. Contributed to the iOS app. Scope: iOS. Links: iOS https://apps.apple.com/in/app/supertails-online-pet-shop/id1670908360 - Ueue (personal, built 0→1 (from scratch), full case study at /work/ueue): A solo-built ecosystem: iOS and Android apps, a browser extension, and a site. Scope: iOS + Android + extension + site. Links: iOS https://apps.apple.com/in/app/save-watch-later-ueue/id6783338928, Android https://play.google.com/store/apps/details?id=com.ueue, Web https://ueue.ziyarex.com/, Extension https://chromewebstore.google.com/detail/jpblogopoikmddifigglmhbmmdlcdkpf - Prism (personal, built 0→1 (from scratch), full case study at /work/prism): Browser extension + site, designed and shipped solo. Scope: Extension + site. Links: Web https://prism.ziyarex.com/, Extension https://chromewebstore.google.com/detail/hehmcipehcghgaiohfmplfckcjckiiai - Insomniac (personal, built 0→1 (from scratch), full case study at /work/insomniac): A macOS menu-bar app that keeps your Mac awake with the lid closed, safely. Scope: macOS app. Links: Web https://saif-09.github.io/insomniac/ - Cat Mode (personal, built 0→1 (from scratch), full case study at /work/cat-mode): A Chrome extension that lets your cat pounce at the screen without hijacking playback. Scope: Extension + site. Links: Web https://saif-09.github.io/cat-mode/, Extension https://chromewebstore.google.com/detail/fnccbbhppojahcammnnoadoajhndeion - Salute Button (personal, built 0→1 (from scratch)): A live web product, running in production. Scope: Web. Links: Web https://www.salutebutton.com/ - Zazz (personal, built 0→1 (from scratch)): A Flutter mobile game with a Go backend, shipped to the Play Store. Flutter for smoother animation than React Native. Scope: Flutter game + Go backend + site. Links: Web https://zazz.ziyarex.com, Android https://play.google.com/store/apps/details?id=com.zazz.game --- ## Site overview (llms.txt) Source: https://saifsiddiqui.in/llms.txt Mohd Saif: Product Engineer I build solutions, not dead software. Full text of every page (all case studies + the complete decision log): /llms-full.txt Mohd Saif is a product engineer with 3.5 years of experience shipping mobile apps, web products, and the backends behind them, end to end, from first sketch through app-store review to production iteration. He has built and shipped products at Shoppin', Wellbeing Nutrition, Gurucool, Zenzop, Supertails, and Infinite Locus, across iOS, Android, and web. Tool-agnostic and outcome-first, with strong applied-AI skills (LLM-powered features and an AI-leveraged development workflow). This site is itself a proof-of-work: multilingual (7 locales including RTL Urdu and Arabic), fully custom, built in the open. The complete decision log behind it is public at /brain. Founding-engineer fit Mohd Saif is a strong fit for a founding engineer role. He defaults to 0→1, having taken multiple products from an empty repo to the App Store and Play Store (Wellbeing Nutrition, Zenzop, the Shloka app at Gurucool, plus personal products like Ueue and Prism). He covers the whole stack (design, iOS, Android, web, and Node/Python backends), makes product and UX decisions alongside the code, ships fast using AI as leverage, and wires up the essentials a young product needs: payments, subscriptions, analytics, and deep linking. His bias is to production: ship, measure with real usage, and iterate. Skills - Core stack: React Native, React, Next.js, TypeScript, JavaScript, Node.js, Python, Firebase, Socket.IO, MMKV, PostgreSQL, MongoDB, Redis, GraphQL, REST APIs. - Payments and monetization: Apple IAP (in-app purchases), Razorpay, Stripe, PayPal, Apple Pay, Google Pay, GoKwik, Qonversion. - Performance and delivery: MMKV persistence, FlashList virtualization, Reanimated 3, deferred deep linking (Universal Links + Adjust + WebEngage), memory optimization, video preloading, A/B testing, CodePush. - Analytics, growth, and tooling: PostHog, CleverTap, WebEngage, Adjust, Google Search Console, Claude Code, Claude API, LLM APIs, Xcode, Android Studio, Notion, Obsidian. Work: professional - Shoppin' (https://shoppin.app/home): AI-powered shopping product; contributed across iOS, Android, web, backend, and product. Current role. Case study: /work/shoppin - Wellbeing Nutrition (https://apps.apple.com/in/app/wellbeing-nutrition/id6654917685): D2C nutrition commerce app, built 0→1 for iOS and Android (Play Store: https://play.google.com/store/apps/details?id=com.coffye.pjfzfc). Case study: /work/wellbeing-nutrition - Zenzop (https://apps.apple.com/in/app/zenzop/id6749267701): delivery Shop and Rider apps built 0→1, with live tracking and iOS Live Activities. - Gurucool (https://play.google.com/store/apps/details?id=com.gurucool): astrology guidance app; built the Shloka app 0→1, then created and owned the Gurucool iOS app. Case study: /work/gurucool - Supertails (https://apps.apple.com/in/app/supertails-online-pet-shop/id1670908360): online pet-care platform, contributed to the iOS app. Work: personal / labs - Ueue (https://ueue.ziyarex.com/): solo-built ecosystem, iOS app (https://apps.apple.com/in/app/save-watch-later-ueue/id6783338928) and Android app (https://play.google.com/store/apps/details?id=com.ueue), browser extension (https://chromewebstore.google.com/detail/jpblogopoikmddifigglmhbmmdlcdkpf), and site. Case study: /work/ueue - Prism (https://prism.ziyarex.com/): site + browser extension (https://chromewebstore.google.com/detail/hehmcipehcghgaiohfmplfckcjckiiai), designed and shipped solo. Case study: /work/prism - Insomniac (https://saif-09.github.io/insomniac/): macOS menu-bar app that keeps a Mac awake with the lid closed, safely. Case study: /work/insomniac - Cat Mode (https://chromewebstore.google.com/detail/fnccbbhppojahcammnnoadoajhndeion): browser extension. - Salute Button (https://www.salutebutton.com/): live web product. - Zazz (https://play.google.com/store/apps/details?id=com.zazz.game): mobile game on the Play Store, built with Flutter (chosen over React Native for smoother animation) and a Go (Golang) backend. Mohd shipped it in these less-familiar technologies quickly by using Claude Code as leverage, a concrete example of picking the right tool for the problem and using AI to ramp fast. Build-in-the-open knowledge graph Every decision behind this portfolio is documented as an Obsidian vault and rendered at /brain, architecture decisions, design system, i18n approach, SEO strategy, and roadmap, all crawlable. Contact - Email: saifmd238@gmail.com - GitHub: https://github.com/Saif-09 - LinkedIn: https://www.linkedin.com/in/mohd-saif-134076141/ --- ## Cat Mode: let the cat pounce, keep the video playing Source: https://saifsiddiqui.in/work/cat-mode Problem Put a bird or fish video on for a cat and the fun lasts about ten seconds: the first paw on the keyboard pauses playback, skips the video, or opens something random. The cat wins, the video stops, and you get up to fix it again. Cat Mode is the small fix: let the cat pounce at the screen without their paws controlling the browser. Decisions One click, everything frozen. The whole product is one toggle. Hit it and Cat Mode freezes keyboard, mouse, trackpad, scroll, and touch, so the video keeps playing through every pounce, headbutt, and full-body slide across the desk. No settings to wade through mid-cat. A human-only way out. Blocking all input raises an obvious question: how do you turn it back off. The unlock is a keyboard shortcut (Ctrl+Shift+K by default, customizable), chosen because it is the kind of deliberate key combination a cat cannot realistically hit but a human presses in a second. Local, private, no accounts. There is nothing to sign into and nothing tracked. Everything runs locally in the browser. A toy this small should not want your data, so it does not. Match the tone to the use case. The whole thing is deliberately silly: pounce-proof, cat emoji, playful copy, because pretending a cat-video locker is serious software would be the wrong call. The restraint is doing one job well and not dressing it up. Outcome {/ TODO(saif): install count when worth stating. /} Cat Mode is live in the Chrome Web Store (https://chromewebstore.google.com/detail/fnccbbhppojahcammnnoadoajhndeion) with a landing page (https://saif-09.github.io/cat-mode/) that explains it in about one screen. It does exactly one thing, block input so a cat can enjoy a video without breaking it, and does that one thing cleanly. Small, finished, and shipped through Chrome Web Store review like anything else. --- ## Gurucool: shipping Shloka, then bringing the app to iOS Source: https://saifsiddiqui.in/work/gurucool Problem I joined Gurucool as an app engineer and got two very different mandates back to back. First, build a brand new app from scratch. Then, fix the one the company already had: a React Native product that shipped on Android but had no iOS version at all. Shloka, built from scratch My first project was Shloka, an app built to bring users back to something calm and daily: the shlokas of the Bhagavad Gita. The backend held the full set of verses, and each one carried its translation, transliteration, commentary, and meaning. I built the app around that: a clean reading experience that pulls a shloka and its layers of context from the backend and presents them simply. I built and shipped it on both iOS and Android from nothing. Bringing Gurucool to iOS Gurucool itself is an astrology guidance app: people consult certified astrologers about love, career, marriage, health, and money through daily horoscopes, chat, on-call sessions, and live video, drawing on Vedic astrology, tarot, numerology, and vastu. That focus on real-time consultation is exactly why the app leans so hard on chat and live sessions, the two things I went on to build and fix. Then I moved onto the Gurucool app team. The app was a single React Native codebase, but only Android had ever been built from it. There was no iOS app, and, as I found out, no ios folder in the project at all. So the first job was to make iOS exist: I created the ios project and its native scaffolding inside the existing React Native repo, then worked through the long tail of everything that breaks when a codebase has never targeted iOS. Pods would not install, the app would not build, the app would not start. I fixed each issue until it compiled and ran, brought the iOS app up to full parity with Android, and published it to the App Store. From there, iOS was mine. I owned the iOS app end to end and co-handled both platforms with the team. What I worked on A chat system on GraphQL subscriptions. I built the app's chat so messages ride GraphQL subscriptions, keeping conversations live without polling. Live video. Agora was already integrated but buggy. I worked through the issues and fixed the bugs so live sessions actually held up. CleverTap for engagement. I integrated CleverTap so the team could see how the app was used and run lifecycle messaging. Structure and optimization. I reorganized the app's files and folders and cleaned up the project so it was maintainable and fast, not just working. Outcome {/ TODO(saif): metrics slot, installs / DAU / session length or retention for Shloka and the Gurucool app. Qualitative until real numbers land. /} Both apps shipped. Shloka went out on iOS and Android from a standing start. The Gurucool app (https://play.google.com/store/apps/details?id=com.gurucool) went from Android-only to a full iOS presence I built and published from a codebase that had never compiled for iOS, then ran with me as the iOS owner across a two-platform team. The through-line is simple: I take an app from wherever it is, missing, half-built, or messy, to shipped and maintainable. --- ## Insomniac: keep the Mac awake, lid closed, without cooking it Source: https://saifsiddiqui.in/work/insomniac Problem I wanted my Mac to keep running with the lid shut. Not dimmed: actually working, an AI agent overnight, an Xcode archive, a long sync, lid closed, no external monitor. macOS calls that clamshell sleep, and it does not care that your task is mid-flight. The catch is in the mechanism. The popular keep-awake tools use IOKit power assertions, and those do not prevent clamshell sleep unless you have an external display, power, and a keyboard attached, exactly the setup I was trying to avoid. The only lever that works with nothing attached is a privileged command: pmset disablesleep. So the whole product is really one thing, a safe wrapper around a dangerous system setting, and everything else exists to make that one lever safe and pleasant to pull. Decisions Safety is the feature, not staying awake. A generic paid keep-awake app is dead on arrival: Amphetamine and caffeinate already do it for free. The unserved angle was heat. A closed lid chokes airflow, and no existing tool says a word about it. So Insomniac is not "stay awake", it is "stay awake without cooking the machine". Measure what macOS exposes honestly, not fake degrees. The tempting version reads a CPU temperature and shows a countdown in degrees. But Apple Silicon exposes no supported way to read die temperature; anything claiming to is reading private keys that break across models. So I built on ProcessInfo.thermalState (nominal, fair, serious, critical), which needs no admin and is supported forever. And the real protection is not an up-front prediction at all: it is a live thermal cutoff that watches the state while the lid is closed and auto-stops the session if it escalates. A prediction can be wrong; a live cutoff is ground truth. An architecture where the dangerous part is swappable. Running pmset as root has two paths: an AppleScript prompt that asks for a password on every toggle (trivial, works day one) and a privileged helper over XPC that toggles silently (production-grade, needs signing and a pinned contract). Instead of coupling the app to either, I hid both behind one PowerControlling protocol. I shipped the password-prompt version on day one and added the silent helper later with zero caller changes. The helper is locked down: as a root daemon it only accepts XPC connections pinned to this app's identifier and Team ID. The safety invariants are enforced by the code. A keep-awake app has one catastrophic failure: leaving sleep disabled after you are done. I treated "never leave sleep disabled" as an invariant and closed every exit. Toggle off, auto-off, thermal cutoff, and battery cutoff all restore sleep. Quit and logout defer termination until the restore completes; the app refuses to die with sleep still disabled. A hard crash cannot be intercepted, so on next launch the app detects sleep disabled with no active session and offers to reset it. There is also no "indefinite": the longest session is a hard 8-hour cap, because "forever" is exactly the setting that leaves a dead, hot laptop in a bag. Honest UI, honest privacy. The app is menu-bar only. The advisory shows a risk level (low, moderate, high) and a plain message, never degrees I cannot read honestly, and the weather nudge is deliberately the weakest input: a hot room can raise risk, but a cold room can never make a cooking CPU safe. The weather location comes from IP geolocation, city-level, so there is no GPS permission prompt; turn weather off and the app sends nothing. No telemetry, no analytics. The bug I only found by living with it. V1 kept the Mac awake, but the screen stayed lit with the lid closed, because disabling sleep also stops macOS from turning the internal display off. A backlight burning against the keyboard is wasted battery and heat, the exact thing the app protects against. I added a lid monitor that fires on the open-to-closed edge and puts the display to sleep with a harmless user-level command, kept deliberately separate from the privileged helper. Least privilege for the thing that does not need it. Ship now, own the rough edge. The core feature needs the App Sandbox off, which rules out the Mac App Store, so I shipped a direct download. Rather than spend days on Apple's paperwork first, I shipped an un-notarized build now and made the resulting Gatekeeper warning a guided, one-minute step: the installer is a hand-drawn setup guide, the quarantine-clearing command sits right next to the app as a copyable file, and the app strips its own quarantine flag on every launch so the warning never comes back. The packaging script re-signs and notarizes with one command the moment a certificate exists. Outcome {/ TODO(saif): downloads / usage once it is public. Qualitative for now. /} Insomniac is live (https://saif-09.github.io/insomniac/): a menu-bar app that keeps a Mac awake lid-closed, with a live thermal cutoff, a battery cutoff, crash recovery, and silent toggling through a signed helper. The whole thing rests on two rules: be honest (the real mechanism, risk levels instead of fake degrees, a weak signal kept weak) and ship fast with the rough edges owned rather than hidden. A keep-awake app is a small thing, but it touches a setting that can damage hardware, so every shortcut that would have made the demo flashier would have made the product less trustworthy. --- ## Prism: extension and site Source: https://saifsiddiqui.in/work/prism Problem Shipping one solo ecosystem could be luck; shipping a second one is a process. Prism, a site (https://prism.ziyarex.com/) and browser extension (https://chromewebstore.google.com/detail/hehmcipehcghgaiohfmplfckcjckiiai), was built to prove the repeatable part: idea → product → shipped, without a team and without a year. Decisions Reuse the playbook, not the code. The lessons from Ueue carried over: surface-per-strength, ruthless scope, states as features. But Prism made its own technical calls where the product demanded different ones. Extension-first. Prism's value lives in the browser, so the extension is the product and the site is its front door, not the other way around. That ordering decided everything downstream: onboarding happens where the value is, and the site sells the click, not the scroll. Ship, then sharpen. First public version early, then iterate against real usage rather than imagined users. Outcome {/ TODO(saif): usage metrics slot, installs / weekly actives, and the iteration story, when you want to share them. /} Prism is live end to end: the extension in the Chrome Web Store, the site in production. The second ecosystem shipped faster than the first, the playbook held, which was the hypothesis. What Ueue proved possible, Prism proved repeatable. --- ## Shoppin': AI shopping, end to end Source: https://saifsiddiqui.in/work/shoppin Problem Shopping online is a search problem pretending to be a browsing problem. People know roughly what they want, "linen shirt, not boxy, under 2k", but stores make them translate that intent into filters, categories, and luck. Shoppin' exists to close that gap: let people shop the way they think, with AI doing the translation. I work on this as part of the product team. My job is product engineering across the surfaces it lives on: the iOS and Android apps, the web experience, and the Node and Python backends behind them, while the product itself is still finding its shape. The role I work here as a product engineer, and the code is the smaller half of that job. Before I build anything I want to know how the feature changes what a user feels and whether it actually moves the product forward. That means living close to the product and design calls, not just the tickets: reading behavior in PostHog, running lifecycle and re-engagement flows through WebEngage, and watching Google Search Console to keep the web surface discoverable. A feature that ships clean but nobody adopts is a failure I can measure, so I treat adoption and retention as part of my definition of done, not someone else's problem. What I work on A generated catalog with an infinite shelf. For the last three months the team has been building the e-commerce side of Shoppin', and it breaks the usual model: the clothes people buy were never in a warehouse. The pieces shown on the app and site are AI generated or sourced, then listed, so the shelf is effectively unlimited and every dress is made to order for one person. No inventory means no stockouts and no dead stock, but it also means ordering and fulfillment have to assume nothing exists until someone actually asks for it. I work across that whole path: the web store, the app, the Node commerce backend, and the Python services behind the generation and AI work. Chat that edits the garment. One of the features I own lets a user talk to the AI and change the clothing itself, tweaking a piece until it is the thing they wanted. The first version worked but was slow and inconsistent, so I optimized the pipeline and the prompting until responses came back fast and reliably on target. It is the part of the product that feels like magic, so it has to feel effortless. Payments, everywhere people pay. I built the payment layer end to end: Razorpay for India, Stripe for international, and native Apple Pay and Google Pay inside the app so checkout uses the payment method people already trust on their device. Fewer taps between wanting the thing and owning it. Subscriptions that work on both platforms. I integrated the subscription system with Qonversion, so recurring plans behave consistently across iOS and Android without hand-rolling receipt validation and entitlement logic per platform. Purchase state and access live in one place, which is exactly where subscription bugs tend to hide. Order updates on WhatsApp. When someone orders, they should not have to come back to the app to find out what is happening. I built the flow that pushes each order update to the customer over WhatsApp, so every status change reaches them where they already are. A dashboard to run the orders. Orders need a place to be managed, so I built the internal dashboard that the team uses to see and move orders through their lifecycle. The customer-facing product is only as good as the operations behind it. Two backends, one product. Node.js runs the commerce and product APIs; Python runs the AI and generation work. Keeping them separate lets each grow on its own terms while the clients stay thin views over a shared contract. React Native for the apps, Next.js for the web. Faster with the right tools. I lean on Claude Code to move quickly across this much surface area without letting quality slip, which is what lets me carry work across app, web, and both backends at the pace an early-stage product demands. Decisions One product brain, many surfaces. With the same small team owning apps, web, and backend, the cheapest architecture was a shared API layer that treats every client as a thin view. Features land once, ship everywhere. The trade-off is that platform-specific polish needs deliberate budget; we spent it where users actually feel it (gesture responsiveness, image loading) and skipped it where they don't. Ship the AI where it earns its keep. LLM calls are slow and expensive relative to everything else in the stack. We kept the conversational layer for intent capture and garment editing, the part users love, and moved everything that could be precomputed to background jobs. The app feels like AI; the latency budget reads like a normal e-commerce app. Iterate in production, honestly. Early-stage products don't survive six-month roadmaps. We shipped small, watched real behavior, and killed features that didn't move usage, including ones we liked. Outcome {/ TODO(saif): when you have shareable numbers, add a metrics list here - e.g. store rating / installs / retention, release cadence / crash-free rate, conversion lift / GMV growth. Until then the copy stays qualitative on purpose: no invented numbers. /} The product is live on the web (https://shoppin.app/home) with the apps in stores, shipping continuously: features land across iOS, Android, and web in the same release cycle, payments clear across three rails, order updates reach people on WhatsApp, and the AI layer runs inside a normal e-commerce latency budget. The strongest signal is cadence: this is a small team iterating in production every week, not a launch that stopped moving. This case study is ongoing; it grows as the product does. --- ## Ueue: a solo-built product ecosystem Source: https://saifsiddiqui.in/work/ueue Problem Most side projects die as repos. Ueue was a deliberate exercise in the opposite: take one idea and ship it as a complete product ecosystem: apps on iOS (https://apps.apple.com/in/app/save-watch-later-ueue/id6783338928) and Android (https://play.google.com/store/apps/details?id=com.ueue), a browser extension (https://chromewebstore.google.com/detail/jpblogopoikmddifigglmhbmmdlcdkpf), and a website (https://ueue.ziyarex.com/), with one person doing product, design, engineering, and release. Ueue itself is a save-for-later app: the calm queue for everything you mean to get to. It captures from any app, sorts your saves into lists, resurfaces them on gentle schedules, and can even pick what fits the time you actually have, so the things you save get finished instead of buried in a bookmark graveyard. Mobile and web stay in sync, a browser extension saves the current tab in one click, and a focus mode with no feed keeps it about finishing, not scrolling. The constraint was the brief: what does it take to run every role at once and still ship something people can install today? Decisions Three surfaces, one spine. The app, extension, and site share the same backend and the same product vocabulary. Each surface does what it's uniquely good at instead of cloning the others, the extension lives where the user's attention already is, the app owns the dedicated session, the site explains and onboards. Scope like a solo dev, polish like a team. Feature list ruthlessly short; states (empty, loading, error, offline) treated as first-class features. A small product that behaves impeccably beats a large one that mostly works. Ship real, learn real. Play Store review, Chrome Web Store review, a live domain, the unglamorous production details are the point. Side projects that skip them prove nothing. Outcome {/ TODO(saif): usage metrics slot, installs / weekly actives, and the one public lesson, when you want to state them. /} All the surfaces are live and reviewed: the apps on the App Store and Google Play, the extension in the Chrome Web Store, and the site in production. One person carried a single idea through three different review processes and three different runtimes, and the ecosystem still behaves like one product, because every surface shares the same spine. --- ## Wellbeing Nutrition: a ground-up app rebuild on Shopify Source: https://saifsiddiqui.in/work/wellbeing-nutrition Problem Wellbeing Nutrition is a D2C nutrition brand with a polished website backed by Shopify. What it did not have was a good app. The existing one was built with Shopify's App Maker, and the experience showed it: it worked, but it never felt smooth. I picked this up at Infinite Locus, and the brief was specific: build a brand new iOS and Android app from scratch in React Native that feels fast and polished, and do it without a new backend. Orders, catalog, and the dashboard would keep running on Shopify, exactly as they did on the web. The interesting constraint was that last part. Shopify wires cleanly into a web React app; there is no comparable path for React Native. Decisions Talk to Shopify directly, from a client that was not meant to. Rather than force a web SDK where it did not belong, I used Shopify's GraphQL API to connect to the store and pull everything the app needed: products, collections, carts, orders. That got real Shopify data flowing into a React Native app with no extra services sitting in the middle. Reshape the data where it is cheap, not where it hurts. Shopify returns data in its own shape, not the shape my screens needed, so the first version fetched from Shopify and cleaned every response on the device. It worked, but processing each query on the phone made the app heavy and slow, the exact opposite of the brief. So I added the one piece the brief did not originally include: a thin Node service that sits between Shopify and the app. It runs the heavy GraphQL queries, cleans and reshapes the data, and hands the app exactly what it needs through a simple API. That single move is what made the app feel smooth. Not everything routes through it: light queries still hit Shopify directly from the app, so I never pay for a hop I do not need. Model the missing pieces with metaobjects. Where the storefront did not natively expose something the app wanted, I created Shopify metaobjects to hold it and fed them through the same pipeline, so the app got a clean, consistent data model without standing up a custom system of record. Ship it as an update, not a new app. The WBN team wanted the rebuild to reach existing users as an update to the old App Maker app, not a fresh listing. I worked out how to take over the existing app so the new build shipped in its place: same users, same store listing, rating untouched. Nobody had to re-download anything, and the switch was invisible from the outside. Login and checkout, bought not built. The no-backend logic applied hardest to the two flows I least wanted to hand-roll: login and payments. I integrated GoKwik for both, so returning customers got fast phone-number login and a checkout tuned for Indian payments, with none of the auth or payment infrastructure landing on me. Instrument it, then engage. I wired in CleverTap for product analytics and lifecycle messaging, so the brand could see how the app was really used and reach people with push and campaigns from launch, instead of shipping blind and adding engagement months later. Outcome {/ TODO(saif): metrics slot, installs / MAU / share of orders via app, repeat-purchase rate or AOV vs web. Qualitative until real numbers land. /} Both apps shipped and are live on the App Store (https://apps.apple.com/in/app/wellbeing-nutrition/id6654917685) and Google Play (https://play.google.com/store/apps/details?id=com.coffye.pjfzfc), delivered as a seamless update over the old App Maker app so the existing audience and rating carried over intact. The result is a fast, native-feeling React Native app running entirely on Shopify, with a small Node data layer doing the heavy lifting only where it counts. The brand kept its commerce stack and finally got an app experience that matches its website. --- ## Zenzop: delivery apps built for the last mile Source: https://saifsiddiqui.in/work/zenzop Problem Zenzop is an on-demand delivery app: food, groceries, medicines, and daily essentials brought to your door. Delivery lives or dies on two things the customer feels directly: do I know where my order is, and is the ETA honest. My job was to build the apps that carry both, from scratch, for iOS and Android. Decisions Two apps, one job. I built both sides end to end in React Native: the Shop app the customer orders from, and the Rider app the delivery partner runs. Each shipped to iOS and Android, so a small team could move on all four surfaces at once. Google Maps handles real-time geolocation and route optimization, the spine both apps share. Live tracking that survives a locked phone. A rider's phone spends the whole trip in a pocket. I built background live tracking so the rider's position keeps flowing even when the app is not in the foreground, and on iOS I went native with Swift to drive Live Activities: order status and rider progress on the Dynamic Island and lock screen, so the customer sees where their food is without opening anything. That is the difference between an app people check and an app people trust. An ETA engine, not an ETA guess. A delivery ETA is a promise. I built an engine that computes it from distance matrices, live traffic, the rider's live position, and historical averages for the route, rather than a naive straight-line estimate. It improved ETA accuracy by 28%, the kind of number a customer feels on every single order. Fast to load, fast to fix. I refactored the apps for 30% faster load times and wired up CodePush, so over-the-air updates ship straight to users without a full store release. Fixes and tweaks land the same day, not the next review cycle. Docs so the API is not a bottleneck. I wrote comprehensive Swagger API documentation so the client and backend teams could build, test, and integrate against a single source of truth instead of tribal knowledge. Outcome {/ TODO(saif): metrics slot, installs / on-time delivery rate / order volume. Qualitative until real numbers land. /} Both apps shipped on iOS and Android: a customer app and a rider app built from nothing, with live tracking that holds up in a pocket, iOS Live Activities on the Dynamic Island, and an ETA engine 28% more accurate than the baseline. The last mile is the part of delivery a customer actually experiences, and these apps were built to make it feel handled. --- ## Portfolio Brain Source: https://saifsiddiqui.in/brain/portfolio-brain 🧠 Portfolio Brain: build in the open This vault documents every decision behind Mohd Saif's portfolio, from day one to launch. It is a real Obsidian vault and the source of the graph view rendered on the site (see Knowledge Graph). The site's north star: North Star - Site as Proof, the site itself is proof of product-engineering skill. Start here - 👤 About Saif - ⭐ North Star - Site as Proof - ❓ Open Questions - 🗺️ Roadmap - 🎨 Design System - 💼 Projects Decisions - D001 - Site as Proof Principle - D002 - Tech Stack - D003 - Visual Restraint and One WebGL Moment - D004 - Case Study Framework - D005 - Contact via Serverless - D006 - i18n Seven Languages and RTL - D007 - Build-time AI Translation - D008 - Fully Custom Analytics - D009 - SEO and AI Crawlers - D010 - Knowledge Graph Build in the Open - D011 - Colour Direction Stone - D012 - Work Section Structure - D013 - Live Demo Ask This Site - D014 - Shoppin Case Study Scope - D015 - Defer Content Translation - D016 - WebGL Uses Plain Three Not R3F - D017 - Defer External Service Activation - D018 - Multi-page and Header Nav - D019 - Visual Richness Overhaul - D020 - Art Direction v2 Bold Monochrome Features - WebGL Hero - Custom Analytics - Internationalization - Contact Form - Knowledge Graph --- Convention: one note per decision, created the moment it's made, linked to the features and phases it touches. The graph grows with the project so the final record is true, not reconstructed. --- ## D001 - Site as Proof Principle Source: https://saifsiddiqui.in/brain/d001-site-as-proof-principle D001: The site is the proof Context: A conventional portfolio tells you someone is good. Saif's goal is subtler, the site should make you feel it. Decision: Adopt one governing principle: every choice must be defensible as a deliberate product decision that demonstrates product-engineering + PM skill. Decoration for its own sake is rejected. Formalized as North Star - Site as Proof. Why: It gives every later call a single test, "does this prove capability, or just look nice?", which is itself the prioritization skill we're selling. Consequences: drives D002 - Tech Stack, D003 - Visual Restraint and One WebGL Moment, D004 - Case Study Framework, and the three meta-proofs Custom Analytics / Knowledge Graph / WebGL Hero. --- ## D002 - Tech Stack Source: https://saifsiddiqui.in/brain/d002-tech-stack D002: Tech stack: Astro + React islands on Vercel Context: Need elite performance, great SEO, multilingual routing, and a few rich interactive surfaces. Guided by D001 - Site as Proof Principle. Options considered: - Next.js 16, familiar, powerful, great if this becomes an app; but heavier JS baseline → harder to hit a flawless Lighthouse on a content site. - Astro 5, zero JS by default, first-class i18n, static-first; hydrate only interactive islands. Decision: Astro + React islands, on Vercel. Next.js documented as the alternative. Why: A portfolio is ~90% content. Astro ships the content as static HTML and hydrates only the islands (WebGL Hero, Contact Form, Custom Analytics, Knowledge Graph). "I chose Astro because the workload is content-led" is itself the product-thinking answer. Trade-offs: less familiar than Next for Saif; if it grows into a full app later, revisit. Enables the perf targets in Design System and Roadmap Phase 0. --- ## D003 - Visual Restraint and One WebGL Moment Source: https://saifsiddiqui.in/brain/d003-visual-restraint-and-one-webgl-moment D003: Restraint + one WebGL moment Context: "Minimal + clean" is non-negotiable, yet the site must impress. Tension between wow and calm. Options considered: - Full explorable 3D world (à la Bruno Simon), highest wow, fights "minimal", heavy on mobile. - Pure minimal, motion-only, safest/fastest, lower novelty. - Restrained + one WebGL moment, type-led, premium 2D scroll motion, a single WebGL hero beat. Decision: the middle path (chosen by Saif). See WebGL Hero. Why: One striking moment against disciplined quiet reads as intentional, "knows where to spend the budget." That contrast is the prioritization signal of D001 - Site as Proof Principle. Trade-offs: less immediately jaw-dropping than a full 3D world; mitigated by nailing motion craft. Motion principles + degradation live in Design System. --- ## D004 - Case Study Framework Source: https://saifsiddiqui.in/brain/d004-case-study-framework D004: Case-study framework: Problem → Decision → Outcome Context: Featured work must prove product thinking, not just output. Saif has the projects; metrics will be filled in by him. Decision: Every featured project (ueue, Prism, salutebutton, Zazz) uses Problem → Decision (calls + trade-offs) → Outcome (metrics) + role, stack, links. Structure now, metrics later (chosen by Saif). Why: Reframes "I built X" into "I made good calls that paid off." Metrics make it undeniable. Directly serves D001 - Site as Proof Principle. Applied across the two-track layout in D012 - Work Section Structure; full list in Projects. Trade-offs: depends on Saif supplying real numbers; placeholders clearly marked until then. Open item tracked in Open Questions (#9 metrics). --- ## D005 - Contact via Serverless Source: https://saifsiddiqui.in/brain/d005-contact-via-serverless D005: Contact via serverless + Resend Context: Site must make contacting Saif effortless, and the contact surface should itself demonstrate craft. Options considered: - Direct links only (mailto/LinkedIn/Calendly), zero backend, but no craft showcase. - Form + serverless function + Resend, a real form with full states. - Form + Calendly embed too. Decision: Form on one Vercel serverless function + Resend (chosen by Saif), direct links alongside. See Contact Form. Why: A form that handles loading/success/error + validation + spam protection perfectly is a live, unfakeable sample of engineering standards, D001 - Site as Proof Principle in action. No DB needed. Trade-offs: a tiny bit more surface to maintain than pure links; worth it. Consent posture still open (Open Questions #6). --- ## D006 - i18n Seven Languages and RTL Source: https://saifsiddiqui.in/brain/d006-i18n-seven-languages-and-rtl D006: i18n: seven languages + RTL Context: Saif wants the site in English, Hindi, Kannada (Bangalore), Urdu, Telugu, Arabic, and Hinglish. Urdu + Arabic are RTL; four are non-Latin scripts. Decision: Build full i18n for all 7 via Astro i18n, per-locale routes, hreflang, dir switching, per-locale Noto fonts. Implementation in Internationalization. Translation mechanism in D007 - Build-time AI Translation. Why: For this audience (recruiters/clients read English) multi-language is a capability demonstration, which is legitimate under D001 - Site as Proof Principle, i18n + RTL is genuinely hard and signals senior engineering. Risk / trade-off (important): quality is binary, fluent Urdu/Kannada impresses; sloppy machine output hurts the signal. Mitigation: English is canonical; each locale ships live only after a review pass. Launch scope + reviewers open (Open Questions #4). RTL handled via logical CSS (Design System). --- ## D007 - Build-time AI Translation Source: https://saifsiddiqui.in/brain/d007-build-time-ai-translation D007: Translations: build-time AI from English Context: D006 - i18n Seven Languages and RTL needs 6 non-English catalogs. Saif said translations come from English. Options considered: - Runtime translation, kills performance, SEO, caching. Rejected. - Manual human translation only, highest quality, slowest/costliest. - Build-time AI translation (Claude) from the en catalog, committed as static files, human-reviewed per locale. Decision: build-time AI translation (chosen by Saif). Why: SEO-clean + cacheable like human translation, cheap + fast like machine. English stays the single source of truth; a build script regenerates the others. On-brand for Saif's AI skills. Trade-offs: raw AI output needs a review gate before going live (esp. RTL/Nastaliq line-breaking + diacritics). Documenting that human-review gate is itself a mature-AI-usage signal. See Internationalization. --- ## D008 - Fully Custom Analytics Source: https://saifsiddiqui.in/brain/d008-fully-custom-analytics D008: Analytics: fully custom pipeline Context: Saif wants an in-site analytics product (like PostHog/CleverTap) showing real visitor behavior, explicitly to showcase skill. Options considered: - Capture with PostHog, build only the dashboard, fastest, reliable, but capture isn't "yours". - Fully custom, own tracker + ingest + store + dashboard. Decision: Fully custom, end-to-end (chosen by Saif). Implementation: Custom Analytics. Why: It's the strongest possible engineering proof under D001 - Site as Proof Principle, the whole pipeline is demonstrably his. Designed to stay lightweight (~3KB tracker, lazy) and privacy-clean (cookieless, IP discarded). Trade-offs: biggest single build chunk (its own Roadmap phase) and adds a datastore (Neon Postgres + Upstash Redis). Honest scaling note for interviews: a columnar store (ClickHouse/Tinybird) at real scale, knowing when to scale is itself the signal. Visibility open (Open Questions #5). --- ## D009 - SEO and AI Crawlers Source: https://saifsiddiqui.in/brain/d009-seo-and-ai-crawlers D009: World-class SEO + AI-crawler friendly Context: Saif wants best-in-class SEO and to be allowed and surfaced by AI crawlers. Decision: - robots.txt that explicitly allows AI crawlers (GPTBot, ClaudeBot/anthropic-ai, PerplexityBot, Google-Extended, CCBot, Applebot-Extended, Bytespider, etc.) + permissive default. - /llms.txt (+ optional /llms-full.txt), clean Markdown summary for LLM consumption. - Localized sitemap.xml (incl. Knowledge Graph notes), hreflang + x-default, per-page/locale meta + OG, JSON-LD (Person, CreativeWork, WebSite, BreadcrumbList). Why: Astro's server-rendered HTML means crawlers get full content without JS. Allowing AI crawlers means Saif's work (and his documented reasoning via Knowledge Graph) becomes citable in AI answers, a modern discoverability edge. /llms.txt is a subtle "ahead of the standards" signal, on-brand for About Saif. Trade-offs: allowing training crawlers means content may be used for training, accepted deliberately for visibility. Compounds with Internationalization (per-locale pages). --- ## D010 - Knowledge Graph Build in the Open Source: https://saifsiddiqui.in/brain/d010-knowledge-graph-build-in-the-open D010: Build-in-the-open knowledge graph Context: Saif wants to document the whole project as an Obsidian-like graph of connected notes, rendered on the site and working in real Obsidian. Decision: Maintain a real Obsidian vault (/brain) documenting every decision from day one, and render it on the site as an interactive force-directed graph. Implementation: Knowledge Graph. Why: Hiring managers rarely see how someone decided. A living decision graph shows judgment, trade-off awareness, and systems thinking directly, the "I reason / I document" meta-proof of North Star - Site as Proof. It also demonstrates real engineering (vault parsing, wikilink resolution, force-graph rendering) and pairs naturally with D009 - SEO and AI Crawlers (crawlable, citable reasoning). Trade-offs: content discipline required, a note per decision, written when the decision is made. Vault is build-time static so it scales to hundreds of notes trivially. Public-scope/rawness open (Open Questions #7). This vault is the first instance of the feature. --- ## D011 - Colour Direction Stone Source: https://saifsiddiqui.in/brain/d011-colour-direction-stone D011: Colour direction: "Stone" (tonal, no hue) Context: Needed an accent/colour system. Saif explicitly rejected the generic AI-default palette (saturated blue/purple/green/orange/neon) as a template tell. Options considered (shown as a visual light+dark mockup board, not hex lists): - Ink & Bone, pure monochrome, warm bone + near-black. - Oxblood, one deep desaturated wine-red signature hue. - Espresso, warm brown → caramel on dark. - Stone, tonal warm greige, no chromatic hue. ← chosen. Decision: Stone. Warm greige paper, charcoal ink; accent is deep charcoal (light) / warm stone (dark). No chromatic colour. Tokens: Why: Gallery-like and calm; forces type, whitespace, and motion to carry the drama, the craft signal of North Star - Site as Proof and D003 - Visual Restraint and One WebGL Moment. Hueless = the least "templated" answer possible. Applied in Design System. Trade-offs: no colour "pop" for attention-grabbing; mitigated by contrast + motion. Escape hatch: if a signature hue is ever needed, add one restrained tone (e.g. oxblood #6E2A2A) very sparingly. Resolves Open Questions #1. Revision (Phase 0): light --muted moved #726D65 → #6D6961, the original measured 4.28:1 on --bg, just under the AA 4.5:1 bar; #6D6961 hits 4.55:1 and is visually identical. See Phase 0 - Foundation. --- ## D012 - Work Section Structure Source: https://saifsiddiqui.in/brain/d012-work-section-structure D012: Work section: two tracks, featured + grid Context: Saif has 11 projects, 5 professional (some 0→1, some contributed) + 6 personal. Showing all 11 as equal deep case studies would look unprioritized, the opposite of the site's signal. Decision: Structure Selected Work as two tracks, Professional and Personal / Labs, each with a few featured deep case studies + a compact grid of the rest. - Featured (~4): Shoppin', Wellbeing Nutrition, Ueue, Prism. - Grid: Zenzop, Gurucool, Supertails, Insomniac, Cat Mode, Salute Button, Zazz. Why: Two tracks let recruiters instantly see he ships both professionally and independently, range + initiative. Curating what earns a deep dive is itself the prioritization signal of North Star - Site as Proof. Each entry states 0→1 vs contributed honestly (seniority reads as honesty). Trade-offs: featured picks can be swapped; grid items still get real links so nothing feels hidden. Depends on Saif's metrics and the Shoppin' shareability check (Open Questions #1). --- ## D013 - Live Demo Ask This Site Source: https://saifsiddiqui.in/brain/d013-live-demo-ask-this-site D013: Live demo: "Ask this site" AI toy Context: Saif wants a small interactive toy on the site (confirmed). Needs to prove product craft first-hand. Options considered: - Distill a shipped product feature, high fidelity but lots of build per project. - Embed Insomniac (existing web toy), cheapest, but generic. - "Ask this site", a tiny AI input answering questions about Saif, grounded in his project data. Decision: "Ask this site" (AI toy). Alternative kept: embed Insomniac if a non-AI toy is preferred. Why: No external product to clone; showcases Saif's AI strength directly; and it ties the whole site together, it answers from the vault and the same llms.txt content that AI crawlers read (D009 - SEO and AI Crawlers). Memorable, on-brand, single-purpose. Tech: Vercel AI SDK + AI Gateway, serverless, streamed, rate-limited, cheap model. Full loading/empty/error/rate-limited states (craft on display). Lazy island. Trade-offs: needs guardrails (rate limit, scoped to grounded answers, refuse off-topic) and a small cost budget. Resolves Open Questions #3 (live demo). --- ## D014 - Shoppin Case Study Scope Source: https://saifsiddiqui.in/brain/d014-shoppin-case-study-scope D014: Shoppin' case-study scope Context: Shoppin' is Saif's current employer (About Saif). Featured as a deep case study (D012 - Work Section Structure), so scope needs a privacy call. Decision: Mixed framing (chosen by Saif), high-level narrative (role, scope, what he owns across iOS/Android/web/backend/product) + real, non-confidential metrics where safe to share. Anything NDA-bound or internally sensitive stays out. Why: high-level narrative gives credibility without risk; a few real numbers make it concrete and land the Outcome. Best of both without overexposing an employer. Guardrail: default to omission when unsure a metric is public; Saif supplies the specific safe numbers at build time (Open Questions). Honesty rule from North Star - Site as Proof still applies, no inflated or invented figures. --- ## D015 - Defer Content Translation Source: https://saifsiddiqui.in/brain/d015-defer-content-translation D015: Defer bulk content translation to a final pass Context: Having Fable translate large content (About, case studies, section copy, brain notes) into 6 locales mid-build burns a lot of tokens for little value, the audience reads English anyway, and translation is a build-time script's job, not Fable's. Decision: Through all build phases, author content in English only. Non-English locales fall back to English key-by-key (already the wired behavior). Run the full content translation as the final step, via the build-time AI script from D007 - Build-time AI Translation (cheap, outside Fable), then per-locale review (D006 - i18n Seven Languages and RTL). Do NOT touch the i18n scaffold or the small UI-chrome strings already translated in Phase 0 - Foundation (nav, switcher, theme labels), those stay. Why: token efficiency; keeps Fable focused on building, not translating; English reaches the whole target audience in the meantime; translation stays a deterministic, reviewable build-time artifact. Trade-offs: non-English visitors see English body content until the final pass, acceptable and reversible. See Roadmap (translation pass added pre-launch). Confirmed (chose A): Fable never hand-translates in any scenario (context bloat + poor quality), so the token worry is moot regardless. The deferral is purely about translating final copy once instead of re-translating changing copy every phase. An early translation pass can be run on demand at any checkpoint (it's the build-time script, not Fable), but the default is the single end-of-build pass. --- ## D016 - WebGL Uses Plain Three Not R3F Source: https://saifsiddiqui.in/brain/d016-webgl-uses-plain-three-not-r3f D016: Hero uses plain three.js, not R3F Context: The spec specified React Three Fiber (R3F) for the WebGL Hero with a < ~120KB gz budget. In practice those conflict: R3F v9 dynamic-imports the whole three namespace → measured 241KB gz, double the budget. Decision: Rewrote the scene as plain three.js with named imports, 129KB gz, same visual, same React lifecycle. Accepted (shipped in Phase 3A - WebGL and Graph). Why: Honors the "performance is a feature" principle (North Star - Site as Proof) without changing the look. 129KB is marginally over the ~120KB target but is lazy, post-LCP, desktop-only (degraded devices download none of it), so real-world impact is negligible, desktop LCP measured 0.6s. Open option (Saif's call): the shader is simple enough to run on raw WebGL (~3KB), dropping ~126KB. Recommended if we want the budget met with huge margin; the only cost is a bit more bespoke GL boilerplate and less future scene flexibility (unlikely to matter for one static field). If chosen, update this note. Trade-offs: plain three = manual scene wiring vs R3F ergonomics; fine for a single field. Supersedes the "R3F" mention in the stack table + WebGL Hero. --- ## D017 - Defer External Service Activation Source: https://saifsiddiqui.in/brain/d017-defer-external-service-activation D017: Defer paid / account-linked service activation to launch Context: Some features need external services tied to Saif's billing/accounts, the AI demo needs a credit card on Vercel AI Gateway; the analytics pipeline needs a production Postgres + Redis. Saif wants to make billing/account decisions at the end, not mid-build. Decision: Build and verify every feature against local/dev services; defer production activation of paid/account-linked services to launch (Phase 7). - AI demo: leave live answers gated (graceful error state shown); add the card + run live grounding checks at launch. - Analytics: build + verify against a local Postgres + local/in-memory Redis; keep the connection env-driven so pointing at production storage later is just env vars. (Neon + Upstash have no-card free tiers, so even prod likely needs no card, provisioned at launch.) - Contact (Phase 5): build the Resend send path env-driven (RESENDAPIKEY); without a key the form degrades gracefully. Real key + verified sender domain added at launch. Why: avoids committing to billing mid-build; features are fully built + verified now; activation is a fast, reversible env/dashboard step later. Same "do it once, at the end" logic as D015 - Defer Content Translation. Trade-offs: deployed previews show empty/seed or error states for these features until launch, acceptable and by design. Everything is reversible in minutes. --- ## D018 - Multi-page and Header Nav Source: https://saifsiddiqui.in/brain/d018-multi-page-and-header-nav D018: Multi-page site + persistent header nav Context: A UX audit (and Saif's own reaction) found the single-page structure (~11,000px scroll) had no navigation, you could only scroll or "back to top," couldn't jump to Work/Brain/Analytics from the top. Decision: Convert to a multi-page site with a persistent, responsive header nav: Home · Work · About · Brain · Analytics · Contact (+ the existing language pill + theme toggle). Home becomes a concise landing (hero + highlights + teasers), not the whole story. Add subtle page transitions (Astro view transitions), reduced-motion-safe. Why: Discoverability + a sense of a real product. Supersedes the original single-page IA, the felt experience beat the plan (D001 - Site as Proof Principle). Supersedes: the single-page narrative in the original §2 IA. Case studies keep /work/[slug]; About / How-I-work / Contact get real pages. --- ## D019 - Visual Richness Overhaul Source: https://saifsiddiqui.in/brain/d019-visual-richness-overhaul D019: Visual richness overhaul Context: The English site shipped text-led with images deferred; the audit + Saif found it "boring / cheap / off", all text on near-black, no product screenshots, no icons, no App Store/Play Store badges, dead scroll space, empty-looking graph/analytics, and (worst) live N stats + [TODO] placeholders in case-study Outcomes. Decision, add real visual richness (keeping the Stone base + the strong typography/i18n/engineering): - Imagery everywhere: real screenshots of Saif's live web projects; device-frame mockups + official App Store / Play Store badges for the apps; product logos; tech-stack icons; section iconography. - Kill all visible placeholders, no N, no [TODO]; real metrics or honest qualitative copy. - Case studies → scrollytelling (sticky device frame + narrative + before/after) not walls of text; next-project nav. - Graph: typed nodes (icon + tone + legend), readable labels (hover/zoom), reliable drag, click-to-focus; fix blank homepage teaser canvas. - Analytics + empty/loading + AI-error states look designed (skeletons, styled error card w/ mailto). - Motion: staggered reveals, magnetic hover, page transitions; FIX the scroll-jump on Work-card hover. Colour: stay on the Stone base (light theme is a strength) + one restrained accent for emphasis/graph focus, richness comes from imagery/icons/motion, NOT a generic saturated palette (D011 - Colour Direction Stone; see the design-taste memory). A curated muted-editorial accent palette is optional pending Saif. Why: "minimal" for Saif still means visually rich + impressive; sparse text read as unfinished. This makes the site walk its own "polish the states nobody screenshots" talk. Partially revisits D003 - Visual Restraint and One WebGL Moment (restraint was over-applied). Built in Phase 7 - Visual and IA Overhaul. --- ## D020 - Art Direction v2 Bold Monochrome Source: https://saifsiddiqui.in/brain/d020-art-direction-v2-bold-monochrome D020: Art direction v2: bold maximalist, monochrome, motion + "dead→alive" WebGL Context: After the Phase 7 overhaul (multi-page, imagery, fixes), the refined-minimal look still read as "boring / not memorable / not unique" to Saif. We reset the direction: Saif chose bold maximalist 2D, wants wide bold type (not condensed), no red / monochrome, heavy GSAP scroll motion, and real Three.js/WebGL. Approved via prototype direction-v2-bold.html. Decision, rebuild the visual language: - Bold maximalist editorial, monochrome cream + ink (keep light + dark; light is the showcase). NO red / no chromatic accent, boldness comes from massive type scale, stark contrast, and motion. - Type: a WIDE, heavy display face (NOT condensed), e.g. Archivo Black / Clash Display / Bricolage Grotesque, huge, filling the viewport. Space Grotesk (UI) + Space Mono (labels). Per-locale Noto bold for non-Latin scripts stays. - Motion system: Lenis + GSAP ScrollTrigger, split-text reveals, pinned scroll sequences, parallax, marquee tickers, magnetic hover, big interactive work-list rows, page transitions. Reduced-motion + RTL safe. - Hero WebGL "dead → alive": a GLSL particle field (Three.js), a dormant dot-matrix that ignites into motion with cursor + scroll, literalizing "I build solutions, not dead software" (WebGL Hero). Scroll-driven ignition; lazy after LCP; capability-gated static fallback; pause off-screen. Keep: all engineering + Phase 7 fixes (multi-page + nav, analytics, /brain graph, AI demo, i18n/RTL English-only, SEO, perf 95+, a11y AA, deferred-service states, real screenshots/store badges/device mockups, RTL bidi). Drop the muddy cloud backgrounds. Supersedes D003 - Visual Restraint and One WebGL Moment (restraint was over-applied); refines D011 - Colour Direction Stone (monochrome kept, but bolder + cleaner) and D019 - Visual Richness Overhaul. "Not perfect but good to go", Saif, 2026-07-17. --- ## Design System Source: https://saifsiddiqui.in/brain/design-system 🎨 Design System Principle: minimal, editorial, timeless. Whitespace + type do the work; motion is seasoning. Reinforces North Star - Site as Proof, restraint reads as taste. Type: variable display (General Sans / Aeonik) + text (Inter / Geist); non-Latin via Noto per script (see Internationalization). Fluid clamp() scale, body ≤ 68ch. Color: "Stone", warm greige, hueless; accent is charcoal (light) / warm stone (dark). Full tokens + rationale: D011 - Colour Direction Stone. Tokens for both light + dark, verified AA in both themes and all scripts. No-flash theme script. Spacing/grid: 8px scale; 12-col fluid grid; generous vertical rhythm. Logical properties everywhere so RTL mirrors automatically. Motion: micro 150–250ms, reveals 400–700ms, hero ~1s; expo.out easing; animate on enter once; transforms/opacity only; prefers-reduced-motion → final states. Full mapping in D003 - Visual Restraint and One WebGL Moment. --- ## Contact Form Source: https://saifsiddiqui.in/brain/contact-form Contact Form Makes hiring Saif effortless, and doubles as a live craft demo. A form that nails every state is an unfakeable sample of engineering standards (North Star - Site as Proof). - Fields: name, email, message, with real-time validation and full loading / success / error states. - Backend: one Vercel serverless function + Resend → routes to saifmd238@gmail.com. Rationale: D005 - Contact via Serverless. - Spam: honeypot + rate-limit. A11y: labels + aria-live feedback. - Direct links alongside: email, LinkedIn, GitHub Saif-09, resume. Open: consent posture (Open Questions). --- ## Custom Analytics Source: https://saifsiddiqui.in/brain/custom-analytics Custom Analytics: "This site, measured" A public, in-site analytics product built end-to-end, the flagship engineering proof. Decision + trade-offs: D008 - Fully Custom Analytics. Pipeline (all yours): custom ~3KB tracker → /api/track ingest → Neon Postgres + Upstash Redis → /api/insights (cached) → custom dashboard - Tracker: cookieless, lazy after LCP, one delegated click listener → {section, element, x%, y%}; scroll depth + time-on-section; named events (demoused, ctaclick, langchange, themechange); sendBeacon batching; DNT-aware. - Ingest: validate, rate-limit, bot-filter, derive country from IP then discard IP. - Dashboard (/analytics + teaser): live visitors, top sections, click map, scroll-depth curve, device/referrer/locale splits, landed→work→demo→contact funnel. Accessible chart alternatives. Ties to Internationalization (locale split) and is the "I measure" beat of North Star - Site as Proof. Privacy note on the page is itself a maturity signal. Scaling answer: columnar store (ClickHouse/Tinybird) at real scale. As built (Phase 4 - Analytics): 2.1KB tracker; env-driven POSTGRESURL + REDISURL; country via x-vercel-ip-country (IP never parsed); session id in tab-scoped sessionStorage (cookieless, anonymous) for MPA funnel continuity; DNT + GPC make it inert. Prod storage wired at launch (D017 - Defer External Service Activation). --- ## Internationalization Source: https://saifsiddiqui.in/brain/internationalization Internationalization Seven locales: English (source), Hindi, Kannada (Bangalore), Urdu, Telugu, Arabic, Hinglish. Urdu + Arabic are RTL. Full rationale + risk: D006 - i18n Seven Languages and RTL. - Routing: Astro i18n, /[locale]/…, hreflang + x-default. - Translation: D007 - Build-time AI Translation, generated from en at build time, committed static, reviewed per locale before going live. - RTL: dir on