# 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, Ziyarex, Ueue, Slate, OreoNotch, Vouch, Prism, Insomniac, Cat Mode, Clickk, 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 - Ziyarex (personal, built 0→1 (from scratch), full case study at /work/ziyarex): The studio: 11 apps, a hand-picked shelf with cons required, 12 free tools, and one manifest behind every surface. Scope: Store + tools + journal + public API + billing. Links: Web https://ziyarex.com - 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 - Slate (personal, built 0→1 (from scratch), full case study at /work/slate): A macOS todo app whose list is your wallpaper. On the Mac App Store, with a paid unlock. Scope: macOS app + in-app purchase + site. Links: Mac https://apps.apple.com/app/id6796836834, Web https://slate.ziyarex.com/ - OreoNotch (personal, built 0→1 (from scratch), full case study at /work/oreo): Live activities and a drawer of widgets in your MacBook's notch. Paid, notarised, self-updating. Scope: macOS app + licensing + site. Links: Web https://oreo.ziyarex.com/ - Vouch (personal, built 0→1 (from scratch), full case study at /work/vouch): A dev tool that tests whether you can still defend the code your agents wrote. Published on npm. Scope: CLI + daemon + dashboard + Claude Code plugin. Links: Web https://github.com/Saif-09/codevouch - 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 - Clickk (personal, built 0→1 (from scratch)): Mechanical keyboard sound for every keystroke, from real switch recordings. Nothing you type is read. Scope: macOS app + site. Links: Web https://clickk.ziyarex.com/ - 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. --- ## OreoNotch: the notch is a UI surface Source: https://saifsiddiqui.in/work/oreo Problem Every MacBook made since 2021 has a notch, and the operating system treats it as an obstacle to route the menu bar around. The two apps that already saw it as a surface split the idea in half: one does live activities well, the other does a drawer of widgets well, and running both is two menu-bar items and two settings windows to hold the same piece of screen. OreoNotch takes the whole surface. Live activities appear as they happen, now playing, AirPods battery, Do Not Disturb, a screenshot you can drag straight out, and one click opens a Desk with media, to-dos, what is next in the calendar, a timer and volume. The hard part is not the feature list. It is that the notch is a region of the screen with no window of its own, and everything you draw there is a transparent panel sitting on top of other people's apps. Decisions The state machine has no AppKit in it. The panel has more states than it looks like: closed, hinting, an activity showing, the drawer open on a tab, and every gesture and timer that moves between them. So that logic lives in a module that imports no AppKit and does no I/O, as a pure function, with the coordinator taking an injected clock. Both are then testable without a screen, which is the only reason 52 tests can cover the behaviour of a thing that exists to be hovered. Visible is not clickable, and it cost me a day to learn. Returning nil from a view's hit test stops the view handling a click, but the window has already taken the event from the WindowServer, so it does not fall through to whatever is underneath. A 900 by 420 transparent panel pinned to the top of the screen made System Settings completely unclickable, and it went unnoticed because screenshots showed the other app perfectly visible around the panel. The fix is to size the window to what it actually draws instead of gating the hit test. The habit is worth more than the fix: for anything that floats, the test is whether the app underneath still responds, never whether it still renders. Hooks so the surface can be photographed without hands. A notch app has nothing you can screenshot without hovering, dragging and waiting, which makes every marketing shot and every visual check a manual act. So the app takes environment variables at launch: jump straight to a settings pane, jump to an onboarding step, hold one activity open indefinitely, open the drawer, open the tray, fill the tray without a drag, skip Bluetooth entirely, write diagnostics to a temp file. A script drives the whole surface. Same reason as Slate's render sweep (/work/slate/): the verification has to be cheaper than the change, or it stops happening. Two toolchains over one set of sources. SwiftPM owns the libraries and the tests, so the inner loop is a fast build with no Xcode in it. Xcode builds the shipping app, because the Focus filter is an App Intent and that metadata only exists in an Xcode build. Rather than pick one and lose either the fast loop or the shipping feature, the project generates its Xcode project from a manifest and keeps both. The cost is a rule to remember, which is written at the top of the readme: after adding a source file, regenerate, or Xcode cannot see it. Always launch it the way a user would. Running the executable directly bypasses LaunchServices, so the privacy system cannot resolve the bundle's Info.plist and the app aborts on the first privacy-sensitive call, even though every usage-description key is present. Nothing in the error says so. It is now the loudest warning in the readme, because the version of this bug that reaches a user is an app that dies on first launch for reasons no log explains. Named so the name is cheap to change. Oreo is my rabbit, which is a fine story for an about box and a poor defence against a biscuit company. So every identifier is name-neutral: the bundle id, the CloudKit container and the preference domain all say notch rather than the brand. A rename now costs strings and assets, not a signing identity and a migration. The icon went the same way. I rendered four rabbit directions side by side, decided they all read as a primitive-shapes animal, and shipped the notch silhouette instead. The rabbit lives in the about box. Outcome OreoNotch is live (https://oreo.ziyarex.com/) at 0.2.0, notarised, macOS 15 and Apple Silicon only, free to download with a $12.99 licence, updating itself through its own Sparkle feed. It is an accessory app with no Dock icon, and the menu it does have includes a debug submenu that fires synthetic activities, because the alternative is waiting for a real AirPods battery event to test the AirPods battery view. Apple Silicon only and macOS 15 only were both deliberate. The notch exists on exactly those machines, and supporting older systems would have meant conditional paths through the one part of the app that has to be pixel-exact. Cutting the audience to the machines the product is actually for is the cheapest performance and correctness decision available, and the one people are most reluctant to make. --- ## 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. --- ## Slate: a to-do list that lives on your wallpaper Source: https://saifsiddiqui.in/work/slate Problem Every todo app has the same quiet failure: you have to go and look at it. The list lives behind a window, a window has to be opened, and so the list is only ever as present as your willingness to check it. The one surface a Mac shows you whether you asked or not is the wallpaper. Close a window, quit an app, come back from lunch, and it is already there. So Slate is not a todo app with a wallpaper export bolted on. The wallpaper is the primary display: a SwiftUI view goes through ImageRenderer to a PNG, then NSWorkspace.setDesktopImageURL puts it behind everything, once per display. The app window and the menu-bar popover exist only to edit the thing you are already looking at. Decisions Rendering to a picture is not rendering to a screen. ImageRenderer will not rasterize a ScrollView, and a SwiftUI Form is one, so the entire settings window is invisible to the renderer by construction. That is not a bug to work around, it is a boundary that decides how the app can be tested: anything inside a Form can only be verified by opening the real window and capturing it. Knowing that early is why the test harness looks the way it does instead of being a pile of screenshot diffs that quietly never covered Settings. Own the store, mirror Reminders, and refuse to approximate. Slate keeps its own JSON store and mirrors Apple Reminders as a second read source. Mirrored reminders are never written into that store; they are merged at read time from the last fetch. No local copy means no drift, no tombstones, and no conflict resolution to get wrong, and a reminder deleted on an iPhone simply stops appearing. Slate writes back exactly two properties, completion and due date. EventKit exposes neither subtasks nor complex repeats, so those are dropped rather than approximated. Every second Tuesday, rendered as roughly weekly, would have demoed beautifully and been worse than absent: a schedule you cannot trust is one you have to check somewhere else, which is the whole problem the app exists to solve. A harness, because no eye scales to seven by nine by twenty-one. Seven wallpaper templates, nine placements, twenty-one palettes, fourteen typefaces and twelve background patterns compose into more states than anyone can look at. So the app ships its own dev CLI and I built it before I needed it. One flag runs 1034 in-process assertions against a throwaway store, never the real one. One stress-renders every template against dark, light, overflow and empty. One writes a wallpaper per pattern and per typeface. One composes the seven App Store product frames at 2560 by 1600, so the store page is a build artifact rather than an afternoon in a screenshot tool. One draws the purchase screen with stand-in plans, because StoreKit returns nothing headless and would otherwise render a priceless, disabled button that misrepresents the normal state. One prints every entitlement StoreKit will admit to and which environment answered, for the day the app insists it is unlocked and you need to know why. That harness is the reason one person can change a renderer on a Tuesday and still ship on Wednesday. The bug that only exists for other people. The very first setDesktopImageURL into a freshly created sandbox container silently no-ops. On my machine, where the container had existed for weeks, this was invisible. For anyone installing from the App Store it would have been the entire first impression: I opened Slate and nothing happened. The fix is a coordinator that re-checks 2.5 seconds after applying and re-applies once, verified against a wiped container. The habit I kept is more useful than the fix: every ship now gets one deliberate pass in a state I cannot reach by developing normally. Two rejections, both facts I could not have guessed. First, the sandbox entitlement com.apple.security.personal-information.reminders does not exist on macOS. The Mac sandbox has addressbook, calendars, location and photos-library, and EventKit reminders live under calendars, which I confirmed by running sandboxed against 22 real reminders across both lists. Second, the Mac App Store requires LSApplicationCategoryType in Info.plist and mentions it only after you upload. Both were fixed the same day, and both are now checked by a preflight script that runs before every archive, because the second time you learn a fact like that is a day you paid for twice. Free to open, paid to keep, and the submission order matters. Slate installs free and a one-time purchase unlocks the rest. Apple reviews an app's first in-app purchase only alongside an app version, in the same submission, and submitting the version on its own is a single click that strands the purchase in a draft reading "unable to submit for review". So the release checklist ends with opening the submission and confirming it lists both items before anything is sent. Pricing and paywall copy are product decisions; the submission order is just a trap, and traps belong in a script. Outcome Slate is live on the Mac App Store (https://apps.apple.com/app/id6796836834), released 4 August 2026 and at version 1.3 within a fortnight, with a landing page (https://slate.ziyarex.com/), a privacy page, and a support page I also wrote. Everything in it is mine: the idea, the renderer, the design system, the seven templates, the palettes, the store listing, the in-app purchase, the hardened runtime, the notarization, and the updates since. The part I would keep from this build is the harness. A solo app has no reviewer and no QA, so the only thing standing between a change and a broken wallpaper on someone's desktop is whether verification is cheap enough that I actually run it. Making it a single command was not thoroughness. It was the only way to keep shipping at all. --- ## 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. --- ## Vouch: a tool that grades me, not the model Source: https://saifsiddiqui.in/work/vouch Problem I ship faster with agents than I ever did without them, and somewhere in that speedup I started merging code I could not have written from scratch. It works, the tests pass, so you move on. Three months later it breaks at 2am and you are reading a file with your own name on the commit like a stranger wrote it. You do not know why that package is there, or what happens when that call fails. The gap between what you shipped and what you can defend is invisible until it costs you, and it costs you at the worst possible moment: an outage, a review, an interview, or someone asking why you did it this way. Every tool in the adjacent space makes the gap worse. DeepWiki, Greptile, Unblocked and friends explain your codebase to you, which feels exactly like understanding and is not, because reading a good explanation is the cheapest possible way to end up confident and wrong. So I built the opposite. Vouch makes me produce the answer first, then shows me the difference. Decisions Test the human, not the output. Every rep opens by asking me to rate my confidence from 1 to 7, before I see anything, and closes by showing the delta. The flagship number is not a score, it is the Gap: how far my confidence ran ahead of what I could actually produce, per area of the repo. This comes straight out of the illusion of explanatory depth, where merely attempting an explanation collapses stated confidence. Capturing the rating before the attempt is not a UX nicety, it is the entire mechanism. A score you can grind is a vanity metric. A number that says you were two rungs overconfident about auth is very hard to argue with. It must never block, and it must never be a code reviewer. No pre-commit gate, no failing build, no permission step. The moment a learning tool can stop you shipping, you disable it and the honest measurement dies with it. That constraint is also the product's whole position: it is not a linter, it does not review the code, and it does not explain it. It asks. Zones gate everything. Nobody wants to stay sharp at everything, and an over-inclusive list of things to be quizzed on is the fastest possible route to uninstalling. So setup is one keypress per area of the code: keep sharp, or outsourced. CSS scaffolding, outsourced, guilt free. Auth and payments, keep sharp. The tool only tests what you said you wanted to own. The score has to stay winnable. My first version put artifact nodes in the denominator with no rep type that could ever promote them, which capped a real repo near eleven percent no matter how much work you did. A learning tool with an unreachable ceiling teaches you that effort is pointless. Now a passing rep promotes the artifacts its decision was about, and concepts are excluded from the score as study material rather than units of ownership. The rule I kept: any new node kind ships with a rep that can promote it, or it does not enter the score. Grounding in real call sites paid for itself twice. Questions are only worth answering if they point at your actual code, so every dependency is resolved to the file and line where it is used, with ts-morph doing the import analysis. That requirement produced a second command I had not planned. If you know every real call site, you know which packages have none. On a production Next.js app, vouch unused found 16 dependencies that nothing imports, 10.7 MB installed, and I checked all 16 by hand: no false positives. Packages that legitimately have no import site, type definitions, eslint plugins, postcss, storybook, are listed separately and never inflate the headline number, and the output calls zero imports a question to answer rather than an instruction to delete. Honest numbers, including the ones that make the tool look smaller. Vulnerability severities are quoted from the advisory database and never invented locally, and dependencies are checked at the version in your lockfile rather than the latest published one, because a project pinned to a vulnerable release would otherwise be reported clean. The prompt reviewer, which reads back the prompts I actually sent and names the ones that should not have been needed, reports its token figure as an estimate and says so in the output: hooks do not expose usage, so it counts four characters per token and charges each avoidable prompt the whole conversation up to that point. The real measurement is the count of avoidable round trips. Dressing an estimate as a measurement would have made a better screenshot and a tool I could not trust. Cheap where cheapness is invisible. Re-tests are recognition items whose distractors are drawn from the repo itself, so revisiting old ground costs zero AI calls. Extraction runs on Haiku, which I moved to after measuring 74 cents per call on a frontier model against 5 cents on Haiku for output I could not tell apart. Decay is evaluated lazily when something is read rather than on a timer, so nothing runs in the background to keep a number fresh that nobody is looking at. Your code stays yours. No account, no server, no telemetry. Redacted excerpts go to Anthropic through your own CLI, package names go to public registries for licence and advisory data, and the outbound host list is enforced in code rather than promised in a README. Environment files, keys and certificates are never sent. One command purges everything and leaves nothing behind. Outcome Vouch is published on npm as codevouch (https://www.npmjs.com/package/codevouch) and open on GitHub (https://github.com/Saif-09/codevouch): a CLI, a daemon, a localhost dashboard and a Claude Code plugin that predicts what it thinks you have not internalised, in the session, before the answer lands. Four waves, 83 tests, Node 24, nothing compiles at install. The reps found real bugs, which was not the goal but is the best evidence the premise holds. Asked to reconstruct a wishlist feature I had shipped days earlier, the brief written when the code landed named three things I had not noticed: a server-side render that throws on localStorage, rapid adds with no client-side dedup, and a storage quota failure that leaves the cache diverged from disk. Three real bugs, surfaced by being asked to explain my own code. The thing I would defend hardest is the refusal to explain anything to the user before asking them first. It makes the tool worse at first impressions and it is the only reason it works. Agents have made producing code nearly free, which means the scarce thing is no longer output. It is whether anybody on the surface still has judgment about it. --- ## 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. --- ## Ziyarex: eleven apps, twelve tools, one file Source: https://saifsiddiqui.in/work/ziyarex Problem I had nine product subdomains and no front door. Slate, Oreo, Clickk, Ueue, Prism, Zazz, Cat Mode and the rest each had a site that knew nothing about the others, so every launch started my audience from zero again. A person who liked one of my apps had no way to find out the same person made the next one. The obvious answer is a studio page listing my things, which solves my problem and nobody else's. Nobody wakes up wanting to browse one developer's catalogue. What people actually want is help deciding what to install, and the reason they do not trust the places that offer it is that those places are paid to recommend. So Ziyarex became a shelf: my apps, a hand-picked shelf of other people's apps with the downsides written in, and the free tools I had already built for myself while shipping. Decisions One file is the product. Every surface is a view over one manifest. The store grid, the homepage, each product's detail page and OG image, the sitemap, a public API, an in-app "more from Ziyarex" list that the Mac apps fetch at runtime, and a cross-promotion strip embedded on all nine subdomains all read the same array. Shipping an app is editing one file. The alternative, a page per product, means every new app is nine edits and a stale one somewhere, which is exactly how a one-person studio ends up with a store that lies. That API is a contract, and it is written down as one. The strip embed and shipped copies of the Mac apps consume the products endpoint, and shipped copies do not update because I renamed a field. So the rule is in a comment at the top of the manifest: additive changes only, never rename or repurpose an existing field. Deciding that before the first consumer existed cost nothing. Deciding it afterwards costs a forced update. The strip needed two implementations, because my sites are two kinds. The newer ones are Next.js. Slate, Oreo and Cat Mode are hand-written static HTML, and no React component reaches those. Rewriting three working marketing sites to unify the stack would have been days of work to serve one strip, so the strip ships twice from one data source instead: a component for the React sites, a small script for the static ones. The duplication is deliberate and cheap; the rewrite would have been neither. Cons required. The Discover shelf carries 24 apps I did not make, and the curation rules are published on the page rather than implied: hand-picked, no paid placements, no affiliate links, cons required. Every listing has to name what is wrong with the app. That single rule is the entire reason the shelf is worth reading, and it is also the reason it can never become a revenue line, which is a trade I made on purpose. Use cases are a separate artifact from features. A store page explains a product in its own language and serves the person who already knows they want it. It fails the person who has read the tagline twice and still cannot picture the day the app improves. So each app also gets a use-case page with its own writing rules, enforced in a comment because I am the only reviewer: a scenario has to be a real moment and has to start with "you", no product nouns the reader has not met yet, tips have to be things a new user would otherwise get wrong, and where the software cannot do the obvious thing, say so here rather than letting someone find out afterwards. Tools are the offcuts, kept. The twelve are things I built while shipping my own apps and did not throw away: App Store screenshot resizing, icon generation for every platform slot, QR codes, a smart store link, an ASO audit, and a set of PDF operations. No watermark, no export cap, no trial that expires, and most run entirely in the browser so the file never leaves the machine. They exist because the free tools I needed all wanted an account and a signature on the way out. Outside makers keep their name. The manifest has a maker field, and when it is set the credit follows the app everywhere: a byline in the store hero, a made-by block with their own links, and Person authorship in the structured data instead of Ziyarex. LinkPeek on the shelf is Kedar Deshmukh's, and the site says so in every place a person or a crawler might look. A shelf that quietly absorbs other people's work into the host's brand is the thing I was building against. Outcome ziyarex.com (https://ziyarex.com) is live: 11 apps in the store (https://ziyarex.com/store), 24 hand-picked apps on the Discover shelf, 12 free tools (https://ziyarex.com/tools), a 24-piece journal (https://ziyarex.com/journal), per-app use cases, a changelog that aggregates every product, comparison and ASO pages, accounts, licence keys and checkout. One of the apps on it was made by somebody else, with their name on it. What I would carry into anything else is the shape rather than the site: put the truth in one file, write the contract down before the second consumer exists, and let the rules that make a thing trustworthy be visible on the page. The cons requirement makes the shelf less profitable and the only reason anyone would believe it. That is usually the trade worth making, and it is always easier to make at the start. --- ## 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. --- ## D021 - Slate and Vouch as Featured Case Studies Source: https://saifsiddiqui.in/brain/d021-slate-and-vouch-as-featured-case-studies D021: Slate and Vouch join the featured case studies Context: Two things shipped after D012 - Work Section Structure was written and were missing from the site entirely. Slate is live on the Mac App Store (id 6796836834, v1.3, released 4 Aug 2026) with a paid unlock. Vouch is published on npm as codevouch and open on GitHub. Between them they are the only evidence on the site for two things the work now leads with: shipping a paid native app through Apple review alone, and building tooling for working with agents. Decision: Both become featured deep case studies with homeFeatured on, ordered 3.5 (Slate) and 3.8 (Vouch), directly after Ueue in the Personal / Labs track. - Slate leads on the render harness and the two App Store validation rejections, not on the feature list. - Vouch leads on the Gap, the measurement it exists to produce, and on the unused-dependency check that fell out of grounding dependencies in real call sites. Why: D012 - Work Section Structure says curating what earns a deep dive is itself the signal. A featured shortlist that omits the only App Store product and the only tool other developers install understates the work by exactly the two dimensions that are currently scarcest. Six home-featured entries still reads as a shortlist rather than a dump. Trade-offs: the featured count goes from 4 to 6, which lengthens the homepage list. Vouch's visual is a screenshot of its GitHub README rather than a product landing page, because it has no public site and the npm page is behind a bot check; its Web link points at GitHub so the browser frame's domain matches what the shot actually shows. The npm link lives in the case-study body and the live-now strip instead. Follow-on: ProjectLink gained a Mac label so the Mac App Store is a first-class store rather than being filed under iOS. It renders the Apple badge with the wording "Mac App Store", and counts toward appsShipped in the derived stats, which moved to 8 apps and 9 live products. Both are still derived from the projects data, never hand-written. --- ## D022 - Ziyarex OreoNotch and Clickk on the Site Source: https://saifsiddiqui.in/brain/d022-ziyarex-oreonotch-and-clickk-on-the-site D022: Ziyarex leads the personal track; OreoNotch featured, Clickk on the grid Context: D021 - Slate and Vouch as Featured Case Studies closed two gaps and missed three more. Ziyarex had grown from the spec's "studio front door" into a live product in its own right: 11 apps in the store, a 24-app hand-picked Discover shelf, 12 free tools, a 24-piece journal, per-app use cases, accounts, licence keys and a public products API. OreoNotch ships at 0.2.0, notarised, with a $12.99 licence and its own Sparkle feed. Clickk is live and licence-gated. None of the three appeared anywhere on the site. Decision: - Ziyarex opens the Personal / Labs track at order 2.9, featured and home-featured. It is the only entry that is a system rather than an app, and it is the container the other products sit in, so it reads first. - OreoNotch gets a featured case study at order 3.6, but not home-featured. The homepage shortlist stays at seven. - Clickk is a grid link-card with no case study, alongside Salute Button and Zazz. Why: D012 - Work Section Structure says the curation is the signal, and the signal was wrong in both directions: the largest system on the site was absent, while the shortlist risked becoming a list of everything. Ziyarex first also fixes the narrative order, since a visitor who meets Slate, OreoNotch and Clickk without meeting the studio reads them as five unrelated hobby apps rather than one shelf. Trade-offs: Clickk's grid card means its interactive keyboard demo, the best thing about the site, goes unmentioned. OreoNotch's case study describes the shipping app at 0.2.0 and deliberately says nothing about the sandboxed Mac App Store build or iCloud sync, both of which are planned and unbuilt. Adding either later is an edit to one paragraph. Not portfolio work: LinkPeek is on the Ziyarex shelf and was built solo by Kedar Deshmukh. It stays off Projects as Saif's work and appears in the Ziyarex case study only as the studio decision it illustrates: the maker field means credit follows an outside maker's app everywhere, down to Person authorship in the structured data. See the note at the foot of Projects. Found while writing this: the products manifest prices OreoNotch at $12 while the live site and its checkout say $12.99. Since that manifest is the single source of truth for the store, the homepage, the OG images, the public API and the strip on nine subdomains, the store is understating the price everywhere except the page that takes the money. Fix in lib/products.ts, not in the site. --- ## 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