The pattern before the projects
Between February and May 2026 my GitHub sprouted a lot of small repositories. Most of them are React apps. A few are Flutter or Kotlin. A couple are HTML files that a static generator spat out. If you scroll my profile from that window it looks like I was distracted, and I was, but there was one underlying thing happening: I was trying every new tool as it came out and each repo is a receipt for one tool I wanted to touch.
The tools were Bolt, Lovable, Replit, Claude Artifacts, and later hand-written Vite scaffolds. The apps were whatever pretext I could think of to actually push a submit button and see what came out. I did not plan this list. I am reconstructing it now from git metadata.
Below are five I remember well enough to describe with any precision. The rest I will list at the end.
Academika (April 3, 2026)
The internal name for this one is unlearned. That is what is in the package.json. The public repo is called Academika because the pretext of the app is a graduation-year retrospective: put in the year you graduated, get a page of what happened that year while you were in school. I built it as an excuse to try React 19 on Vite 8, both of which had just landed.
The whole app is two components. LandingPage collects the year. ResultsPage renders the retrospective. State lives in App.jsx as a single number or null (the repo is JavaScript, not TypeScript). The URL syncs to a ?year= param via history.replaceState, so refresh works and share links work. That is the entire product surface.
What I learned: React 19 on Vite 8 with no other dependencies boots in about twelve seconds from npm create to npm run dev, and the resulting bundle is small enough that you never think about code splitting for a two-page app. Also, having the URL be the state store is the correct default for anything shareable. I had been putting things in localStorage for years without thinking about it, and this repo is where I stopped doing that.
VerifieR (April 3, 2026)
This one has more code. VerifieR takes any answer, sends it to a Supabase edge function called verify-answer, and comes back with a verified answer object that has a share token. The share URL is /share/<hex> and the top-level App.tsx watches window.location.pathname for that shape on mount.
The thing I remember about this repo is the edge function. Supabase edge functions run on Deno, and up to this point I had only written serverless code on Node runtimes. The edit loop was different. You write your function, deploy it with the CLI, and it runs in a real V8 isolate at the edge with a cold start under a hundred milliseconds. The mental model I had from Vercel functions did not carry over cleanly. You do not have a node_modules. You import from URLs. The CORS layer is your problem.
I did not ship VerifieR anywhere. It sits at initial-commit and never got a second push. But it is the first repo where I wrote an edge function that took a real payload, hit an LLM API from the server side, and wrote the result to Postgres in a single request. Everything I have written since that talks to Supabase edge functions started from this one.
whatstime (April 3, 2026)
whatstime is the only app from this stretch that I actually use. It is a Chrome extension that watches WhatsApp Web, reads the currently open chat header, looks up that contact's timezone from a Supabase table, and injects a small overlay next to the name that says something like "It is 2:17 AM in Tokyo, maybe wait." I built it because I kept messaging one specific person at bad hours and feeling bad about it after.
The architecture is a content script that runs on web.whatsapp.com, a background service worker that syncs the contacts table every thirty minutes, an options page for adding contacts, and a Supabase table with row-level security so my own contact list is private. The Supabase migration is in the repo. The extension folder is separate from the Vite app that hosts the landing page for it.
The interesting part of the build was the DOM observation. WhatsApp Web replaces DOM nodes constantly as you switch chats. A MutationObserver at the document root fires hundreds of times a minute. The extension has to detect when the visible chat header changes, extract the display name, and only then hit the database. I got it wrong three times before landing on watching for a specific data-testid on the header container. Once that was stable, the rest of the extension was around forty lines of code.
I still have this loaded in Chrome. It has caught me a handful of times.
toppler (April 7, 2026)
Full name in the package.json is titan-toppler. This is a physics destruction game. You swipe to flick a large orb around a vertical city and try to smash towers before a collapse line rises past you. Web-first via Vite and TypeScript, physics via matter-js, and a Capacitor Android shell so the same game can be published as an APK to the Play Store.
I never published it to the store. But the scripts folder is a fossil record of me trying to. There is a publish-doctor.mjs that checks whether every required Play Store field is present, an android-bundle-release.mjs that runs the Gradle bundle command, a release-verify.mjs that runs after a build to check that legal pages exist. There is a twa-manifest.json for the Trusted Web Activity path. There is a legal page generator that produces support and privacy pages at build time.
I remember spending a whole Saturday on the Capacitor sync flow. Capacitor copies your dist into the Android project's assets folder, and if you have stale files from a previous build the Play Store rejects the bundle with an integrity error. The android:clean-assets script exists because I hit that rejection twice. The scripts folder is longer than the actual game code. That ratio is honest for what happens when you try to ship a hobby game to a real store.
scholarships (April 3, 2026)
scholarships is the odd one. It is not a React app. It is one HTML file, one CSS file, one app.js, and a SCRATCHPAD.md that is longer than the code. The pretext of the app is a list of scholarships an Indian student can apply to for a US masters. The interesting file is app.js, which starts with a sourceLedger array. Every entry has an id, a tier of primary or secondary, a scope, a URL, and an accessed date. Every scholarship in the visible list is tagged with which ledger entries support each claim.
I built this because I wanted a research artifact where you could not add a scholarship without also adding a source. The scratchpad on disk is not the app. The scratchpad is a template for how I run research agents. It has a "Recovery Block" section that gets filled every time an agent fails, and a "Fast Restart Checklist" that says re-run the last known-good command before trying new paths. That template outlived the app. I have copied that recovery block into three other projects since April.
The scholarships site itself is one page. But the discipline in that repo, source-mapping every claim, is the thing I learned. I have not written a research page since without a source ledger.
The rest, one sentence each
exploding-expansion-engine, bookish-betrayal, skillsdb, podhost, creatinefordsa, livespan, app-page-hero, animated-infographic-studio, trainly-india. All Lovable exports from a single week, all with the identical # Welcome to your Lovable project README, each one me trying to see what Lovable would produce for a different prompt and pushing the export to git so I could diff against my own hand-written scaffolds later.
DynaClip (February 2026, HTML). A Windows clipboard history utility built as a Dynamic Island pill at the top of the screen, PyInstaller-packaged with an Inno Setup installer, a pre-release audit doc, a QA matrix, and release notes.
jot (May 2026, Dart). A Flutter quick-capture notes app scaffolded with a proper LAUNCH.md and design references, meant to be store-ready for iOS and Play but never submitted.
timespin (May 2026, JS). A Flutter app for Play Store publishing automation, wrapped in a large harness of CDP and keyboard-driven scripts (around sixty kbd_*.cjs and cdp_*.cjs files) that drive the Play Console, plus data-safety CSVs and a store_assets/ folder. The primary language reads as JavaScript because the automation harness is bigger than the Flutter code.
thought-stream (May 2026, TS). A Bun-based journaling scaffold; interesting only because it is the first repo where I actually used bun.lock instead of npm.
ivr (April 2026, Kotlin). An India-first IVR shortcut project with a working Next.js app (middleware, app router, components, lib/), a Supabase schema, a Dockerfile, and an Android auto-dialer proof of concept in android/. Past scaffold, still pre-launch: no live users, no store submission.
cope (April 2026, Java). An Android app scaffold, gradle-generated, never past initial commit.
enigma (April 2026, HTML). Six saved HTML files named Git Reporting Tool - Automated Reports to Slack & Email (N).html (the unnumbered base plus one through five), living alongside a full Vite project (src/, dist/, package.json). The story is me iterating on a single artifact by re-exporting from an AI chat five times and then trying to build the real Vite version from the fifth export.
ache (April 2026, HTML). A build_site.py that reads a GRE issue-pool PDF and generates one static HTML page listing all the essay prompts.
aarogyavaani (April 2026). A repo with a LICENSE file and nothing else, which is what happens when I claim a name for a hackathon idea and then do not build.
vitascale (April 2026, Python). A Docker-based Hugging Face Space entry, the first repo where I wrote a Dockerfile for a public deploy.
CollageCreator and CollageCreatorSaaS (May 2026). Two Replit-generated Node monorepos for a photo collage tool with a drizzle config; the first was the demo, the second was me trying to fork the demo into a paid version and stopping.
design-extract-output (May 2026, HTML). A static site containing screenshots and extracted CSS tokens from a design I liked, kept as reference material.
trainly-india (March 2026, TS). An earlier Lovable export than the April batch, the first one I pushed to see what the Lovable-to-git flow was.
DND (February 2026, TS). A drag-and-drop practice app.
research-agent (April 2026), Antigravity-AutoAccecpt (February 2026), Remotion-video (May 2026), remotion (March 2026), blitz-windows (March 2026), hackathon-explorer (May 2026), .claude (May 2026), Linkedin-Auto-post (July 2025). Utilities and experiments, each one about one tool I wanted to poke at for an afternoon.
hackathon-playbook (May 2026) and Chromium-extension- (August 2023). Private repos. I am not going to open them for this post.
What the batch adds up to
Looking at this pile, most of these are not products. They are handles I built so I could hold a tool. The Bolt exports are handles for Bolt. The Lovable exports are handles for Lovable. The Capacitor scripts in toppler are a handle for the Play Store submission pipeline. Even the Supabase edge function in VerifieR is a handle for Deno edge runtimes, wrapped in a pretext about verifying answers.
If I had to pick one thing this class of repo taught me, it is that the pretext matters less than I thought it did at the time. What survives from a weekend spike is the piece of infrastructure you had to wire up to make the pretext work at all: the Supabase RLS policy, the MutationObserver on the WhatsApp header, the Capacitor asset-clean script, the source-ledger template. Those pieces show up in later projects and the pretext gets forgotten. Two of these repos, whatstime and scholarships, gave me something I still use. That ratio, two out of about thirty-five, is roughly what I expect from a stretch like this.
See also
- /blog/typescript-prototype-graveyard-2025-2026, the sibling pile.
- /blog/five-portfolios-before-this-one, same over-open-a-repo pattern.