What I'm building

Started a new project and took it through the structured kickoff in a day: the problem written down, the first customer identified as the venue rather than the visitor, and the stack picked. Two things were done deliberately rather than optimistically. The big thesis — that queues at a hospital, a sweet shop and a temple are one product rather than a hundred — was separated from the small, testable bet, because only the small one can be checked in four weeks and merging them is how you end up with a demo nobody can prove wrong. And the strongest argument against that thesis was written into the plan rather than discovered later: the queue itself may be common while the rules for who gets served next are not, and if those rules carry the real complexity then a general tool is worse than a specialised one at every single venue. The claim that nothing like this exists was also marked down as an assumption to go and verify, since competing products do exist and the first venue owner asked will name them.

Set out to put the manufacturer's specifications into the app and learned two things by reading all 520 pages of one. First, an owner's manual carries no power, torque, acceleration or mileage figures at all — those are brochure numbers — so the honest version of the feature shows what the manual really has (dimensions, capacities, tyre pressures, fluid grades) under a label that says where it came from. Second, the tool used to pull tables out of the PDF had been scrambling the columns, and had already published the vehicle's maximum loaded weight under the label for its empty weight. That correction shipped on its own, ahead of the feature. The panel keys on the make and model the owner typed, never on the body shape they picked to be drawn — because the sedan shape in the picker is named after one specific car, so an owner of a different sedan selects it quite reasonably and would otherwise have been told his car has another manufacturer's engine. The rest of the day went to the paperwork half of the app — a document vault and a service-history timeline, with service dates joining the existing reminders — and to two fixes worth naming: buttons were dimming their own labels below the contrast floor while held, and the automated render-quality score turned out to be unfixable by re-tuning its weights. Working out exactly why produced a better fix than the one that had been asked for.

Spent the day chasing why one vehicle renders patchy while the other looks right, and found the answer one layer below where everyone had been looking. Every quality check in this pipeline compares the finished render against the reference photograph it was built from — so if the photograph itself draws the vehicle in the wrong proportions, it scores perfectly against itself while every correct 3D model scores badly against it. The scooter's reference draws it about a quarter too long and low. What finally proved it was buying nothing: a 3D model generated by a completely different commercial service, which had never seen our reference images, scored identically to the in-house one — and then both models agreed with each other, and with the real vehicle's measurements, against the photograph. Two independent makers agreeing against the reference is what points at the reference. The wrong conclusion had survived five separate investigations. Two checks now print the mismatch automatically, one of them a minute into the process rather than twenty. Along the way: a fix for surfaces being rendered as polished mirror, and a real bug in the file reader that made any outside 3D model measure as a perfect cube — inside the very code that is supposed to catch a model being the wrong shape.

Ran the vehicle pipeline end to end on a scooter — the first time anything but the original car had been through it. The good news came fast: the reference images passed the input check on the first try, and four minutes of compute turned them into a textured, recolourable 3D model that is now in the app. The useful news was the failures. An entire stage of the pipeline had never actually executed, because it is skipped whenever an earlier result already exists and the first vehicle always had one — so the moment a new vehicle reached it, three separate bugs surfaced at once, including one that would have written a huge intermediate file over the finished model. Adding a vehicle and replacing an existing one also turned out to be different jobs: the checklist only covered things that read the model, not the two commands that quietly rebuild it. Looked at on a real phone, the verdict was that the shape is right but the surface is patchy — which matters, because the patchiness is the worst-scoring thing on the automated report and the shape is not, so the score is weighted wrong against what a person actually notices. Flooding each region of the texture with a different colour and re-rendering put a number on it: roughly a quarter of what you see at the app’s opening angle is an invented surface, sitting exactly on the flat parts an owner looks down at. Four candidate fixes were tried and measured, and all four failed, which is its own answer — the fix is two more reference photographs, not another setting.

The 3D car had visible patches on it, and two rounds of fixes had aimed at the wrong thing — first the surface finish, then the model being too coarse. The answer came from a two-minute trick instead of another theory: flood one region of the car's texture with a garish colour and re-render, so every patch fed by that region lights up. All of them did. The patches were the roof, bonnet and boot — the parts no camera had ever photographed, which the tool had been inventing by smearing the side view sideways. A real overhead photograph had been available for a day but was switched off after making things worse; the cause turned out to be a single hardcoded threshold tuned for a windscreen's angle, which sent the shallower rear window to the invented roof instead of to its own photograph. With that fixed the overhead view earned its place, and the owner confirmed on a phone that most of the patchiness had gone. The bigger find was in the measuring tool: it graded the car from four directions, all horizontal, so the roof — over 40% of what you see at the angle the app opens on, and the exact thing under argument — had never been graded by anything at all. Two other things were worth as much as the fixes: a promising improvement scored twice as well as the passing bar, was shipped, and was then rejected outright by its owner on a real phone, which makes three such disagreements in a row and demotes the score to a safety net rather than a judge; and a planned week of work on the surface finish was cancelled after one measurement showed it could not possibly have been the cause.

Spent months treating “make the render look like the owner’s actual car” as a question of finding a better 3D reconstruction. It is not. What makes a car recognisable — grille pattern, badge, light signature, the chrome line around the windows, the panel gaps — is a few millimetres of surface relief, which survives in a photograph and dies when that photograph becomes geometry small enough to ship to a phone. The previously built reconstruction route proved it by shipping a car with no grille, no badge and flat disc wheels. The replacement keeps the picture’s pixels and repaints only the bodywork: given the same studio render of a car in a light and a dark colour, the pixels that changed are paint and the pixels that did not are glass, tyres, chrome, badges and lamps — a split derived from evidence rather than guessed from the shape of the model. It recolours across the whole palette with every identifying detail intact, and ships smaller than the 3D model it replaced. Two lessons were expensive enough to write down: a workaround added for a bad input stayed after the input was fixed and quietly became the defect it was hiding, and four wrong diagnoses in a row came from reasoning off a rendered picture instead of printing the numbers — so the tool now reports what it measured and refuses source images it does not trust.

Added a reconstruction route to the model workshop: a handful of AI-generated reference views of a real car become a rough 3D model, which a new pipeline then makes app-ready — welding it into a single paintable body, separating the glass and tyres so they stay dark under whatever paint the owner picks, and baking soft ambient shadow into the recesses for depth without baking in a colour. Two real vehicles went through it end to end, a Honda Activa scooter and a Hyundai Verna car, each added as an opt-in variant that leaves everyone else's vehicles untouched. Also corrected the car paint from an accidental liquid-chrome look to a real finish (colour under clear lacquer, not metal), gave glass, lamps and trim distinct finishes, and fixed a genuine crash that only showed up on a real phone. Finally rebuilt the offline preview tool to run the actual renderer, after the old shortcut turned out to be flattering a broken material and letting a bug slip through to the device.

Built a hand-authored hatchback as the control for the rendering bake-off, then reviewed it three times against a rendered contact sheet — and every round found structure, not polish. No wheel arches (the body's underside sat level with the tops of the tyres, so no wheel was ever inside an arch). Wheels standing clear of the bodywork in open air. A windscreen torn open by two surfaces fighting for the same 0.9mm. Mirrors floating a hand's width off the car with no stalk. A cabin sitting on the body like a hat — its roof width turned out to be the wheel-track measurement, copied. Underneath all of it was one recurring mistake, now on its fifth appearance: a part positioned at a remembered constant rather than against the surface it touches. Since the body tapers, any remembered number is wrong by construction — and the only reason to guess was that nothing published the real answer. It does now, so parts ask. Worth noting what didn't help: the automated model checker passes cleanly through every single one of these defects. Only looking at the rendered thing catches them.

Cleaned up the last few colours that were hardcoded directly into components instead of pulling from the shared design system — one turned out to be legitimate (a car's actual paint colour, which correctly shouldn't repaint itself when the app's theme changes, so it moved to a data file instead), the other a real gap that's now fixed. That cleanup also surfaced something worth knowing: the app's launch screen still shows stock branding from the starter template rather than the app's own look — noted for whenever it's worth a design pass. This project is now the first in the lineup to pass every automated check clean.

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.

Replaced the old blue app icon with a black-and-white mark matching the rest of the interface, generating every size Android asks for plus the store listing image — and the files got dramatically smaller on the way. Separately, the design system now keeps a local copy of its stylesheet with an automated check that the phone app still matches it, so the two drifting apart becomes a failing test instead of something spotted by eye later.

A to-do tagged for either of the two newest projects would vanish. Not fail — vanish: filed to an inbox by the server, then dropped from the phone screen entirely by a second, separate hardcoded copy of the project list being used as a filter rather than a sort order. Two real to-dos had been in the store, listed correctly on the laptop, and invisible on the phone since the 7th of the month, with no error and no empty state to hint at it. Both copies are gone; the list is now read live from the one file that defines it, and the tag shorthand is interpreted on the server where that live list is — which meant the already-installed app was fixed without rebuilding it. Tag matching also stopped being case- and punctuation-exact, since the name you naturally type on a phone is rarely the exact internal spelling, and an ambiguous tag now resolves to nothing rather than guessing, because a wrong destination is worse than a recoverable one. Alongside: the project cards were rewritten to lead with a one-line status and the single next action instead of a 200-word paragraph, and the test suite was made to actually run on Windows — it had been failing for a shell-syntax reason on a codebase where every test passed, which is the kind of red light people learn to ignore.

Renamed the Book tab to Learn and gave it a per-course progress card, so study progress and the architecture notes share one surface. The rename follows the scope rather than leading it.

Re-synced the app with the design system that authors it, after last session's redesign had quietly drifted away from it. The interesting part was the diagnosis: the colours weren't wrong, the structure was. Screens were reading raw palette values directly, with no layer in between saying what each value was *for* — so the only way to build a dark mode was to swap the raw values, which is why it kept coming out inverted and wrong. Putting that role layer back makes dark mode a straight swap of two values, with no per-screen special-casing anywhere. The design system also dropped its soft-shadow card style, for a reason worth keeping: a shadow needs a third tone, and a two-value system doesn't have one. Depth is now a 3px edge in the opposite value, one hero card per screen carries the inverted fill, and a whole gradient library came out with the effect it existed to paint. Also recorded the link to the design project itself for the first time — nothing pointed at it before, which is exactly why the drift went unnoticed for a session.

Applied a complete black-and-white visual redesign across every screen, sourced from a from-scratch design system — a strict four-colour palette where meaning comes from shape and weight, never colour — plus a live light/dark mode toggle. Dark mode took two false starts before it was right: a literal colour-swap read as correct on paper but was nearly unreadable on the phone, and a next attempt introduced new colours that broke the palette's own four-colour rule. The version that stuck reassigns which role each of the same four colours plays per theme, so every part of the UI stays correctly readable automatically, and every card in the app — not just the accent moments — now sits as a bold block of contrast against its page. Also traced down why the app had stopped opening on a real phone: it had drifted onto a newer platform version than the phone's installed testing app supported, and pinned it back in line.

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.

Six weeks dormant with a decision long overdue, this restarted as an app rather than a messaging service — possible because a sister project had meanwhile built a real class-10 maths engine the kid can work through directly. Three earlier decisions were reversed, and the test each had to pass was whether reversing it deleted work rather than merely postponing it. Dropping the messaging platform removed a business-verification process, a set of approval-frozen message templates, a signed webhook with its retry-idempotency handling, several secrets and a recurring per-family cost — but the deciding argument was not cost. It was that template wording freezes at approval, and the wording of that one dinner-table question is the entire hypothesis being tested, so the platform would have locked the copy during exactly the phase meant for learning what works. Switching to email and password removed a telecoms registration; a magic link was rejected too, since in a native app it has to deep-link back in. The reasoning was written into the repository rather than left in a machine-local scratch file, and the superseded milestones were closed with banners instead of deleted, because their question bank and prompts seed the new build. Recorded honestly: none of this adds evidence of demand, which remains the real risk.

No product movement — tooling sync only, for the fourth review running. Recording it plainly: the pilot verdict is overdue and the project is dormant in practice, whatever the label says.

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.

Started a new project and took it through the structured kickoff in a morning: the problem written down, the hypothesis stated as something falsifiable, the stack picked, and no code written on purpose. Two choices carry most of the weight. The first is that the smallest version of this experiment involves no software whatsoever — find five people with a talk in the next month, have each send a phone recording of one rehearsal, and return a written critique within the hour. The measured signal is deliberately not whether they liked the feedback, but whether a second recording arrives within a week without being asked; if it never does, the idea can die in week one for the price of five emails rather than after a month of building. The second is a small technical line drawn early: the parts of the feedback that are arithmetic — pace against the time budget, filler-word counts with timestamps, where the real point actually arrives — are computed from the transcript rather than asked of a language model, which is reserved for the one genuinely hard judgement of what the three biggest problems are. A cheaper model was ruled out by name on the grounds it would produce generic praise, which is exactly the failure the product exists to avoid. Video and body-language analysis were excluded for a reason worth recording: a camera makes people not want to press record at all. The honest gap coming out of the day is that the intended user was never specified and got assumed — a working professional with a conference talk, versus the original idea of helping kids — and those are two different products with two different sets of people to go and talk to, so nothing downstream is safe until it is settled.

Turned a loose Bauhaus theme draft into a written source-of-truth document, so the standing question becomes execute-or-shelve rather than keep-drafting.

Added a check that reads the live database's migration ledger and verifies a migration was genuinely applied, rather than trusting a note someone left in a commit message. It closed this project's oldest open item on its first run: the fix had in fact been applied days earlier, and the note saying otherwise simply had no way to find out. The point generalises — 'written and committed' and 'actually live' are different states, and only the second one counts.

Retired a set of old, hand-run database scripts that a couple of files were still (incorrectly) pointing to as the source of truth — the real, versioned migrations had quietly become the actual schema months ago. Then built three automated checks that catch what a type-checker can't: one of them found and closed a genuine access-control gap in how new memberships were created, and another caught a date-validation bug where a slightly malformed date (like February 30th) was accepted by the form and only rejected — confusingly — by the database. Also added a first layer of automated tests, timezone-aware for an Indian audience.

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.

Tapping “decide the date” from the main card dropped the host on a screen insisting no date poll existed; backing out and tapping again worked every time. The launcher passed no identifier, so the screen re-derived which party it meant from a cache keyed to the group — the kind that answers instantly with possibly-stale data and then refreshes — and the very first read committed to whatever was already there. Now the screen is told which party it is for, rather than inferring it. Logged as a known issue with the root cause written out, since the interesting part is the failure mode rather than the fix. Separately, venue seeding reached a second city: four entries added there, five more in an outer suburb of the first, and a review that cut two previously-added rows — both had solid contact details but nothing showing they actually host this kind of party, and fit alone is not the bar. Contact numbers are taken from each venue’s own website after finding that one aggregator number fronts several unrelated venues, and that one hotel publishes a different number on a booking site than on its own.

A month of real use produced two roster problems from opposite directions: a member on the dues list who had never actually joined, leaving the ledger permanently short by her share, and a member added the day after the party who the host agreed should still be part of it, invisible to the month because the dues list is written once when the party is created. Fixing them by hand meant building a proper removal path first — one that refuses when someone has paid, when the month is settled, when she is hosting, or when she is the last admin, and that keeps a full snapshot of anything it deletes. Writing each guard in terms of who it protects is what exposed a bug in one of them: it was blocking a member who had no stake in the month at all, on the strength of other people's payments. Both incidents went into a new log for real occurrences that are neither bugs nor feature requests, and together they reframed a shelved feature — the problem was never 'removing a member', it's that the month's roster is a snapshot and reality drifts from it in both directions.

Built the release binary that had been pending for two weeks and configured the store submission track. Completed the live tambola loop: the host can record winners so there's no end-of-game confusion, players get a self-marking mode by default, tickets rotate into a full-screen landscape view without losing their marks, and a finished game can be replayed on the same tickets. Also capped the login verification call so a hung request can't leave the spinner turning forever — a fix that, it turned out at week's end, landed two hours after the build was cut and so isn't in anyone's hands yet.

Hardened the money side of the app, server-first. The headline bug: changing a group's monthly fee fired three separate writes with no transaction around them, and the third one was permitted under a different rule than the first two — so whenever the person making the change wasn't the current party host, the first two writes committed and the third was rejected. Since hosting rotates around the group and being an admin doesn't, that mismatch was the *normal* case, and it left the group's fee and its member dues disagreeing with no way to see or repair it from inside the app. It's now a single all-or-nothing operation that checks permission itself. The tempting fix — widening the existing rule to admit admins — was deliberately rejected: it would have opened a different hole, in the same shape as one closed a migration earlier. A separate pass also tightened the rules on what a member may change on her own ledger row, restoring what those rules had always claimed in their own comments but never actually enforced. Both are invisible from the app itself; no behaviour changed. Also ran the feature gate on a member-removal feature and the answer came back *don't build it* — no user has ever asked for it, it'd be used about once a year, and it would rewrite the permission layer underneath work that hasn't been verified on a phone yet.

Found and fixed a gap where two real database objects had been living only in files marked as data rather than in the versioned migration history — invisible unless you knew to look, and would have silently vanished on a from-scratch rebuild. Then swept 22 hardcoded colours back into the shared design-token file, mostly copy-paste that had drifted from the system without anyone deciding it should; one genuine gap surfaced in the process — gold-on-gold text that had been correctly hand-fixed in two places because the proper token simply didn't exist yet, which it now does.

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.

The tutor's 'break this into smaller steps' feature turned out to have been broken on the live site since the day it shipped. It read its teaching spec from a file path assembled at runtime, which the build's dependency tracing could not see, so the file was never bundled into the deployed function and every single request failed. The interesting part is the failure mode: the error was caught inside a block that treats problems as 'the model produced bad content', so a missing-file deployment fault appeared in the logs as a content rejection and pointed the blame squarely at the prompt. The fix was as much about taxonomy as about tracing — failures are now classified by who has to act on them, so 'the deploy is wrong' can never again disguise itself as 'the model misbehaved'. The rest of the session opened the mastery model up for spaced review and made the step renderer chapter-agnostic, so a sister project can run short daily sessions over the same material.

Ten focused commits turned 101 static lesson steps into something that responds to the student: the teaching method written down as a spec, a concept graph tagging every step, a model that weights recent evidence more heavily than old, on-device progress, and a map of what is solid. The centrepiece is a generation pipeline with a deterministic verifier in front of it — every arithmetic claim a model writes is recomputed before a student sees it, and the gate rejects all-or-nothing, catching false equations, factorisations that don't multiply back, and worst of all wrong answer keys, which would tell a correct student she was wrong. It deliberately declines to judge what it cannot check, because unverifiable is not the same as wrong. A rejection is treated as a normal outcome rather than an error: the student simply gets the hand-written hints she would have had anyway. Also fixed the type-checking gate that had been reporting a meaningless red for weeks — it now genuinely passes.

Running the project's own quality gates for the weekly review turned up something worse than the known styling debt: the type-checking gate had never been running at all. Without the compiler installed locally the command was silently resolving to an unrelated placeholder package and failing for a reason that had nothing to do with the code — the most misleading kind of red, because it looks like debt you already know about.

Adopted a shared code-quality check across the site's projects. It immediately surfaced pre-existing debt — dozens of hardcoded colours in two older components that should be reading from the shared design tokens instead — now tracked as the next cleanup item.

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.

Workspace tooling sync; no product work. The oldest open items — verifying the account-linking flow on a real device, and settling the store audience declaration before submission — are unchanged.

Added the same live-database migration check the other projects got. Here it reports a clean skip — and that's the useful result: the project turns out never to have been linked to its database on this machine, which surfaced only because something finally tried to look. It reports 'not set up' rather than passing or failing, on the principle that a check which can't see the database shouldn't claim the database is fine, and shouldn't cry wolf either.

Added a first real automated test suite — 49 tests covering scoring, streaks, and the daily question set. One of the very first tests written caught a genuine bug: replaying the same day's daily quiz was silently resetting a player's streak back to one, even a long one — a case two related pieces of logic had quietly disagreed about for a while, hidden by how the screen happened to be built. Fixed it, and added the kind of test that would catch it again: not testing either function directly, but asserting that the two agree with each other across every state. Also fixed a broken build check that had gone unnoticed.

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.