What I'm building

Turned the next two build stages — a private document vault with service history, and add-a-vehicle-by-photographing-a-document — into detailed, build-ready specs with explicit quality bars (a wrong extracted date counts worse than none). Then mapped nine milestones beyond them, each with its own start gate: store test release, the owed round of user interviews run against the real app, a render pipeline that makes any user's vehicle look showable, accurate per-vehicle facts with a zero-wrong-facts bar, a shareable pride card, light theme and polish, public release, iOS, and a deliberately code-free investigation of a second product category. Also fixed the 3D view so a black car is actually visible, and made the app degrade gracefully in the development sandbox.

Closed the design milestone end to end: a style exploration across eight looks settled on a museum-inspired visual language (serif nameplates, a single mint accent, dark theme first), which was then audited — every text pairing passes accessibility contrast in both themes — and rendered as 24 real phone-sized screen mockups with per-screen build notes. Built it in the disciplined order: design tokens in code first, then a shared component kit with no raw colors or sizes anywhere, then the screens composed from that kit — sign-in on real authentication, an add-vehicle form whose save reveals a 3D profile of the car, a reminders view for insurance and emissions-check dates, and local notifications. The backend moved onto versioned, re-runnable database migrations instead of a one-shot setup script.

Closed out the v0 milestone after confirming the app runs on a real phone, and moved into user-interview mode: wrote the working question set — deep on vehicle ownership, anchored in stories about the last time something actually happened, with a short zoom-out testing the broader “own with pride” idea — plus outreach messages designed not to bias the answers, and rules for consent and anonymising notes. Separately, researched how realistic the 3D vehicle display can get, comparing scanning a real car, AI-generated 3D models, catalog models, and pre-rendered spins — and planned a bake-off: one cheap test per approach, scored on which one actually sparks pride, with the winner adopted in the upcoming design pass. Also did a privacy pass ahead of wiring real services: anonymous user ids instead of emails, analytics pinned to EU servers with session recording off, and a living privacy doc that records each decision as it’s made.

Built the first playable version: a sign-in, a garage of your vehicles, and a vehicle profile centred on a real-time 3D model you can spin on a turntable, lit like a studio shoot. Got it running on a real phone, and explored several starkly different visual treatments for the 3D display to carry into the design phase.

Turned the app’s tambola (housie) from a single-phone number-caller into a game the whole group plays together on their own phones. The host draws numbers on her phone and every player’s ticket marks itself automatically in real time, with a private “you’ve got a line — call it!” nudge on the winner’s own screen — no public announcement, so she still shouts it out the way the game is meant to be played. Each player taps to claim which ticket is hers so the app knows whose is whose. It went through a full pre-build review (is it worth building now, what could break, how it flows), then the build, and closed with a security review (a player can’t grab someone else’s ticket mid-game) and a usability review (clearer wording so no one sits waiting for the app to announce a win). Also made the Venues directory work across two cities with a toggle. Next: trying it on real phones in an actual party. The Play Store tester links are now published on this page too — both the closed-testing track (the current one to join) and the original internal-testing track.

Built a new Venues tab: a read-only, browsable directory of party venues for one city to start, each with a tap-to-call or WhatsApp contact and a host action to set one as this month's venue. It's a hand-curated list rather than scraped, so it can ship with genuinely real places — which also means it stays empty and needs its venue list populated before it's useful, the one thing gating the feature. Put a fresh build on the Play Store's testing track, and fixed two launch problems a tester hit: replaced the stock loading screen with a branded splash so there's no flash into the app, and capped a startup step that could otherwise hang the app open until it was force-closed and reopened.

Ran a thorough pass over the whole app looking for bugs and rough edges, and found five worth fixing: a dismissed welcome card in one group was silently hiding it in every other group; a screen meant to show "everyone's responded" could never actually reach that state; a light-mode flash on startup; a payment screen that didn't live-update when someone else marked themselves paid; and a create-group button that stayed clickable while silently doing nothing on empty input. Alongside the fixes, tightened up the money-handling code paths so the balance display goes through one shared calculation everywhere instead of separate copies, and a badly-formatted payment ID now gets caught with a friendly message instead of silently breaking the pay link. Also trimmed one more unused native dependency.

Put the project's visual design system on rails: it can now be pushed to a shared design canvas as a single source of truth, and a new check verifies — automatically, at the end of each work session — that every screen in the app is accounted for, with its design and its code kept in step (it currently tracks all 28 screens). Also introduced a lightweight planning step before any new feature is built: a short, recorded brief that weighs whether it's worth it, what could break, and which screens it touches, so a feature gets thought through before code rather than during. Built as a reusable setup so the same workflow carries across projects.

Fixed the image-share feature on the web version, which had been quietly failing for every web user. When you send a party update or a settled-month summary, the app turns the on-screen card into a picture and hands it to your phone or browser's share menu to post into WhatsApp. On the web this had three separate breakages stacked on top of each other — the underlying screenshot tool doesn't run in a browser, the browser's share couldn't carry the generated picture, and the share was being triggered a fraction too late for the browser to permit it. Reworked the web path to capture the card directly in the browser and to show a small preview-and-share step, so the share menu opens reliably; on browsers that can't share a picture, it now saves it so you can attach it yourself. Also replaced a raw technical error on the sign-in screen with a plain 'check the number and try again' message. Still to be confirmed on a real device.

Fixed two ways the web build could show a blank screen. Startup no longer waits indefinitely on resources like fonts and settings — it shows a splash, offers a retry after a few seconds, and as a last resort renders with whatever has loaded, so one stalled step can't freeze the screen. And after a new web deploy, a returning visitor whose browser had cached the old page now recovers automatically instead of breaking on a file that no longer exists. Added lightweight startup tracking to confirm the real cause in production.

Ran a thorough review pass over the whole codebase. Tightened a few security edges — phone numbers are now sanitised before being dropped into dialer and WhatsApp links, and a powerful internal database-maintenance function was locked down so ordinary app users can't reach it. Removed some duplicated code and brought the project's documentation back in line with what the app actually does today, after a few weeks of fast changes had let it drift. A multi-pass review of the changes turned up no real bugs — the one flagged issue was checked and proven a false alarm. Finally, corrected the privacy policy: the analytics tool does receive members' names as a label, so that's now disclosed plainly in both the in-repo policy and the public privacy page, rather than describing the analytics as fully anonymous.

Membership changes now propagate live to all open screens via a realtime channel — renames, new additions — so no one needs to manually reload. Added a per-person food-and-drink preferences view in the party coordination screen, and made phone numbers visible in the members list with one-tap calling and WhatsApp. Reworked the date-decision flow to match how it actually gets used: proposing a single fixed date now runs a proper confirm-and-RSVP rather than a one-option comparison poll, and hosts can re-open a vote after a date has already been agreed. Completed the Play Store listing — a branded 1024×500 feature graphic, finalized store tags and privacy URL, and scripts to normalize the screenshot set.

Worked through the Play Store app-content and data-safety questionnaire by auditing it against the actual code rather than a written spec — which caught two mistakes in the draft: an allergies note mis-filed as health data, and location quietly being collected. Fixed the location leak at its source — analytics was deriving an approximate city from each request, so that was disabled and raw network addresses are no longer stored, honouring the app no-location promise. From a hands-on user walkthrough, added the missing welcome messaging: a celebratory group-kickoff card when a new kitty is created, and a ready-to-share “you have been added” note for each new member, so the host can post them straight into WhatsApp. Refreshed the live web demo.

Uploaded the first Android build for internal testing, and published the privacy-policy and account-deletion pages a store listing requires. Polished the profile screen along the way — the light/dark toggle now leads with a sun/moon icon and a clear label, and some food and payment wording was tidied across all three languages.

Switched the app's default language to English, with Hinglish and Kannada now opt-in from the profile — a product call that English should be the baseline while the regional voices stay one tap away. None of the existing translations changed, only which one shows first. Finished the last untranslated corner from the day before — the food and drink preference labels — so the whole app now follows the language switcher. Then ran a cleanup pass over the recently written code: folded nine copies of an identical screen wrapper into one shared component, merged two byte-for-byte identical data modules into a single parameterised one, and removed some now-unnecessary type escape hatches — all pure restructuring with no change in behaviour, kept honest by the type-checker, linter and tests. One rule held throughout: anything the app sends out to the whole group stays in a single fixed language, so everyone reads the same message whoever sent it.

Added English, Hinglish and Kannada across the entire app, with a switcher in the profile that repaints every screen in place the instant you change language. Built a small in-house translation system rather than pulling in a library: one canonical English key set that the other languages are type-checked against, so a piece of text can't quietly ship half-translated. Then worked through every screen and shared component — the dues ledger, date polls, food and menu planning, the host picker, tambola, and the rest. One deliberate rule throughout: anything that leaves the app for the whole group — the WhatsApp messages, the shareable status images, the printable tambola tickets — stays in a single fixed language, so a mixed-language group all reads the same thing whoever sent it; dates stay in English too. The Kannada is a machine draft awaiting a native-speaker review, and one set of food-preference labels is queued for a later pass. Verified by the type-checker, linter and tests; on-device verification still to come.

Added a spin-the-wheel alternative to the existing draw for picking the next host — a real choice the user can flip between, remembered on their device. Restructured the screen so switching is instant: the data loads once in a shell that stays put while only the picker swaps, after a first version that reloaded everything on every toggle. Also surfaced the chosen menu and games on the party card and its shareable status image, pulled every action onto that one card, gave the date screen a one-tap way back to the party, and replaced the placeholder app icons with the real branded set. Refreshed the live web build.

Built a feature straight from a customer request: a playful draw that picks who hosts the next gathering from whoever hasn't hosted yet this rotation, then sets up the next month with that host. Who's eligible is derived from the group's real history — everyone hosts once, then the rotation resets on its own — and is covered by unit tests. The draw stays re-rollable for fun while the step that actually creates the next month is the binding one, and it sits alongside the existing path for when the host is already known. Shipped to the live web build.

Fixed the failures only real usage finds: an onboarding deadlock, auth flows hanging on spinners, sign-out breaking on web (React Native's Alert is a silent no-op there), and phone-number paste handling.

Built a share layer that pushes generated images into the group's WhatsApp — live party-status snapshots and month-end settled-ledger summaries — plus handover flows for date polls and food preferences. First production Android build completed. Deliberately deferred deep-link infrastructure as premature at current scale.

A bold-festive design reset, landed safely: backward-compatible design tokens first, then a full component layer (buttons, cards, sheets, chips and more), then every screen migrated. Dark mode became the default with an in-place reactive toggle.

Rebuilt navigation around how a real host describes the app: a home listing all your kitty groups, each opening into a stack of months, each month a party hub where the coordination features live. Added multi-kitty membership, admin settings, and archived groups.

Shipped date-decide polls, food preferences, tambola with themed tickets and a calling board, and a living party card. Rewrote every user-facing string in Hinglish for the actual audience. Wired a PostHog event funnel to measure whether the core ledger loop is really used. Closed with a documentation audit reconciling plans with the shipped app.

From blank repo to a live product slice: wrote the one-pager, ran five user interviews (Mom Test style), and let them pick v1 — a dues ledger for the group. Interviews reframed the target user from the host alone to the whole kitty group. Built phone-OTP onboarding and a ledger running on live data, with settle-month and self-pay flows.

Brought a full CBSE class-10 maths chapter (Real Numbers) into the site as a new course — 101 short, sequential steps a student walks through with next/previous navigation and a contents page, each its own fast-loading page, all generated from a single lesson data file so the course can grow to hundreds of steps without hand-wiring navigation. It carries live, hands-on widgets: an interactive factor tree, an HCF/LCM explorer, and a maths playground, all restyled into the site's own look. Rebuilt the homepage in a fresh visual style that leads with the two courses that are live now while keeping the rest of the catalogue reachable, each course marked as a work in progress.

The site grew a catalogue of self-paced courses (share trading plus exam-prep tracks like CAT, CLAT, GRE and Bank PO) and also became the home for the companion apps' public landing, privacy and account-deletion pages, which their app-store listings link to.

The optional email sign-in from the previous session is now committed: a player can back up and restore their profile and stats across devices by verifying a one-time code, with the on-device profile re-homed under the real account and backed up to the cloud immediately so nothing is lost if they leave mid-flow. Landed alongside a cleanup pass that folded repeated answer-feedback and category-image logic into shared reusable pieces and slimmed the profile and first-run screens.

Started adding an optional email sign-in so a player can back up and restore their profile and stats rather than being tied to a single phone — verifying by one-time code, then re-homing the on-device profile under the real account and backing it up to the cloud immediately so nothing is lost mid-flow. Alongside it, folded repeated logic (answer feedback, the category images) into shared reusable pieces and slimmed down the profile and first-run screens. Still mid-flight and not yet committed.

Reviewed the whole app for bugs and size. Found a real one: the colour feedback on a correct/wrong pick was being silently overridden by a styling-order mistake, so it never actually showed. Also added a way to leave a live head-to-head match once it's started — previously the only exit was from the waiting room, so backing out any other way left your opponent stuck waiting forever. On size, stripped about 7MB of illustration images that were still being bundled even though the feature using them is switched off, and adopted a faster image-loading library.

Rolled the app back from an accidental Expo SDK 55 jump to the intended SDK 54 — major upgrades should be deliberate, not a side effect of a loose version range. Restored two missing router dependencies and fixed an iOS icon configuration key so the light/dark icon variants resolve correctly.

Grew all twelve trivia categories to 70 questions per difficulty — 2,700 questions total, enforced by a validator. Added Class 10 schoolwork as a new kind of section: each subject is its own walled-off section and each chapter a category, so adding a subject is a configuration change, not a refactor.

Added weekly leagues with automated closing — moved the scheduled job from CI cron to pg_cron so it lives next to the data. Built an AI-assisted question-generation pipeline. Followed with a code-review wave: centralized game rules and category definitions, tightened types.

Built and released the full game in six days: the pick-wrong mechanic with time bonuses and streak multipliers, a seeded daily challenge identical for every player worldwide, true/false rounds with explanation cards, shareable score cards, and translations.

The in-app architecture handbook grew triage powers: chapters now sort by freshness and each shows when it was last reviewed (“reviewed 5d ago” / “not reviewed yet”), a collapsed section lists the concepts flagged for future chapters with how long each has been waiting, and every chapter ends with tappable links to its related chapters. The backend call that serves the book now carries that extra data in a backward-compatible, read-only way — so the whole book backlog can be triaged from the phone without opening a laptop. A fresh sideloadable build is the remaining step to get it on-device.

Added a Mission view that reads my own public portfolio and activity data and renders every project as a card alongside a GitHub-style activity heatmap whose cells tap open to show that day's work — so the phone mirrors the website with no rebuild, updating itself each time the portfolio is published. Gave the app a new icon, splash and favicon set and ran a design pass across all tabs, with project links now shown as tappable chips. Renamed the marketing tab and split it into YouTube and X sections, and built a fresh sideloadable Android build so all of it is usable on the phone.

Committed and shipped the YouTube stats view and Google Play numbers work that had been sitting ready since the previous session. Then ran a code review focused on app size: the code itself was already solid, so the pass mostly cut weight — removed three unused native packages and about half a megabyte of leftover template images and dead code.

Turned the last two placeholder tabs into working features: the todo list and the architecture handbook now read and write straight from a private Git repository through small passcode-protected serverless functions, so the phone and laptop always share one source of truth — an edit on either side shows up on the other. Headline metrics are computed on the server, so a metric can change with a redeploy and no new app build. Later the same day, gave the app a real identity — a custom glowing icon and the ability to swipe between tabs — and added two new at-a-glance number sources: Google Play stats (installs, rating, crashes, reviews) folded into the metrics view, and a new YouTube tab pulling channel and video numbers across all the products. Both new sources run as small key-protected serverless functions — wired and ready, waiting on their access credentials and a fresh build.

Built a personal Android dashboard that shows key product numbers at a glance. The analytics key is never shipped inside the app — a small passcode-gated serverless function holds it and runs a fixed set of read-only queries, so the installed app carries zero secrets. Chose a native app over a web page to sidestep browser limits when calling analytics, and reused infrastructure already in place for the backend rather than adding another vendor.

Worked through a backlog of code-quality findings from an earlier review. Removed two leftover debug surfaces that could have exposed a signed-in user's session token, fixed a bug where driver names were showing as blank on the dashboard after an earlier data-model change, and tightened up a data-access gap in the documents feature so every table now double-checks it belongs to the right organisation. Also closed a handful of smaller hardening and cleanup items. Checked the app's overall size and dependencies while at it — already lean, nothing to trim there.

Finished the monthly attendance-and-payroll summary that had been left mid-build. Then replaced raw, technical error messages across every form and API in the app — a badly formatted email, for instance, used to surface as a wall of validation code; it now shows one plain sentence, checked both as you type and again on the server.

Began a monthly per-driver attendance summary aimed at payroll. Added an organisation-maintained holiday calendar and treats Sundays and holidays as paid rest days, worked out from the calendar rather than entered by hand — with the option to override a particular day for a particular driver when reality differs.

Built a driver attendance feature: a daily register where a manager picks a date and marks each driver present, absent, on leave or half-day, plus a monthly column on the drivers list showing days worked with a hover breakdown. Saves are one row per driver per day and designed to be safely repeatable, and drivers left unmarked are deliberately not recorded rather than defaulted. Also cleaned up production builds to strip debug logging.

Revived the project with a concentrated build: trips with lifecycle rules (capacity checks, double-booking prevention), shipments with auto-status, bookings, invoices, and a documents module with per-organization storage quotas. Reworked drivers as standalone roster records — most drivers never log in, so requiring an account was the wrong model. Role-gated every mutating API.

Settled the multi-tenant security model: tenancy enforced at two independent layers (database row-level security plus repository-level scoping) so a missed filter fails closed instead of leaking data. Built a generic typed CRUD repository that every table reuses.

Scaffolded the app — dashboard, core pages, authentication and roles, database schema — with a mobile-first, duotone visual identity in vanilla CSS.

Turned the Real Numbers teaching page from something you read into something you do: a practice engine that walks through questions with hints that unfold one step at a time, and live, hands-on manipulatives — an interactive factor tree and a Highest-Common-Factor / Lowest-Common-Multiple explorer — so a student can work the ideas rather than only watch them. Also began preparing the chapter's teaching material the way it's actually taught in a session: broken into progressively smaller pieces until each one clicks, ahead of the first live tutoring session.

Collapsed an earlier multi-screen prototype into a single, fluid page that teaches one maths chapter (Real Numbers) end to end — the key idea, the core theorems with worked examples, a full irrationality proof, the textbook exercises, and a ready-to-run session plan — with the official textbook and exemplar PDFs one tap away in a sticky bar. Gave it a bold two-colour design sampled from a reference image and tuned for readability, then deployed it live so it can be used during real tutoring sessions. Also refocused the project around one real student and tutor using it continuously rather than a round of user interviews.

Kicked off a study companion for a CBSE class-10 student: wrote the one-pager, then built a mobile-first web app — a daily focus card, a colour-coded topic-mastery map, and practice and progress views — running on placeholder data as a stimulus for upcoming user interviews. Turned the first maths chapter (Real Numbers) into an interactive teaching page built from the official textbook: the core theorems, a worked irrationality proof, textbook practice, and a ready-to-run 40-minute session plan. Then rebuilt the whole interface into a real design system — colour tokens, a distinctive type pairing, a shared component layer, consistent icons, and considered motion — after a first flat draft didn't hold up. Kept the bulky textbook files out of version control.

Ran and recorded the first discovery interview with a prospective family, and wrote it up honestly rather than flatteringly. In a home where a parent already teaches and the child talks freely about their day, the specific gap the product targets didn't show up, and there was no appetite to pay for another study tool. Kept it as data to pressure-test who the real audience is — not a verdict from a single conversation.

A planned day off pushed the pilot schedule back by one day. Rather than sliding the final verdict date with it, kept that deadline fixed and spent one of the buffer days built into the plan — buffers exist to absorb exactly this, and a self-imposed deadline only works if it doesn't move. Also rehearsed the first spoken pitch for recruiting pilot families.

Kicked off from a research-backed concept: retrieval practice and spaced repetition are the revision techniques that demonstrably work, and WhatsApp is where Indian families already are. Deliberately wrote zero code — the first test is a fully manual, scripted seven-day experience run by hand with real families: a daily ten-question quiz for the student and one dinner-table prompt for the parent, drawn only from answers the student got right. Drafted the complete kit (day-by-day message script, a 60-question Class 10 bank, an operator manual), then verified every question against the official NCERT textbooks programmatically, catching and fixing three errors.