@Osmosis

This is the part I think actually makes InSave different, so I wanted it to feel good. The problem: everyone’s got a graveyard of saved reels they’ll never see again. InSave lets you dig it up. You hand it the data file Instagram gives you when you ask for your stuff, and it lays out every reel you ever saved so you can grab the few that mattered and let the rest stay buried.

The thing I cared most about: your entire saved history never leaves your phone. It gets read right there on the device, and only the handful you actually choose to keep ever get sent anywhere. The graveyard is yours and it stays yours.

Two bugs nearly slipped through, The syncing code was telling itself “yep, saved that” for reels it had not actually saved, so on a bad day reels could just quietly disappear with no error to tell you. That’s the worst kind of bug, the silent one. Fixed it so it only ticks a reel off once it can actually see it stored. The second was smaller, hit “keep all from this person” twice and you’d get duplicates. Made it so keeping something twice does nothing the second time.

Where it landed: 46 tests passing, up from 20, and a clean build. The whole import-and-triage flow holds together end to end. Still to do on the real phone, feed it an actual Instagram export and confirm it really does make zero calls out to Instagram while you browse, which is the promise the whole privacy story rests on.

One lesson I’m taking, bugs are a pain in the a** when you dont even know where theyre coming from, bugs that lose your data while smiling at you is worse than one that crashes.

More to come!

First piece, and the most important one, because if saving a reel is even slightly annoying nobody will do it, me included. The goal was brutal: tap share, tap InSave, and you’re already back to scrolling. No screen, no typing, no “tag this now.” Under a second.

The part I’m quietly proud of, it does zero network on the way in. When you share a reel, everything happens right there on your phone (clean up the link, check you haven’t already saved it, write it down) and only later does it quietly sync in the background. Which means it works with no signal at all. Save a reel in a lift with no bars, it just works, and catches up when you’re back online.

The wall was a dumb one that I almost shipped past. The little “saved!” confirmation popup broke when offline, the one moment it most needed to work, because the page it lived on tried to load fresh and couldn’t. Fix was to bake that popup into the part of the app that’s always cached, so it shows up even with no connection. Annoying to find, satisfying to kill.

Where it stands 20 tests, all green, and a clean build. The save-while-offline-then-sync loop holds together. Real on-phone testing (does it actually show up in Instagram’s share menu, does it really feel under a second) is the next thing I have to check on the actual device, not just in tests. But hey thats not the only thing, there’s a lot more work to be done…

Devlog 3
A public demo, backend and all, with no backend
The problem with showing WeekLog to anyone outside my team: it needs a Cloudflare Worker, a D1 database, and R2 storage to do anything. You can’t just hand someone a link and let them click around. So for a Stardance demo I needed a version that runs entirely in the browser, with realistic data, that nobody can break.

Here’s the thing that made it almost free to build: every single data call in the app already went through just four functions in one file (api.ts). I set it up that way months ago so the UI never talks to the network directly. So to fake the entire backend, I didn’t touch a single feature screen. I swapped those four functions to delegate to an in-browser mock instead of fetch, ported the red/amber/green compliance logic verbatim out of the Worker, and seeded sample data into localStorage with dates relative to today so the demo always shows a realistic spread of healthy and flagged days. A little “DEMO · Reset” pill in the corner lets anyone wipe it back to clean.

The lesson worth stealing: if every network call in your app funnels through one tiny choke point, you can replace your whole backend with a fake one without rewriting the app. This is the second time that one boring decision has paid off (the first was dropping in a full redesign without touching the logic).

It’s honest about its own shortcuts, documented in a DEMO.md: uploaded image blobs live in memory so they show a placeholder after a refresh, and the ZIP export downloads a manifest instead of real zipping. Real Supabase magic-link auth is kept so the sign-in flow is genuine; everyone who logs in is just made an admin over the sample data.
40/40 tests pass, clean production build, tsc clean. Live as a static site on Cloudflare Pages, no Worker behind it. More to come: wiring the real Google Drive connector, a proper compliance summary view, and per-file delete.

Next up: wiring the real Google Drive sync, a team-wide compliance summary view, and per-file delete.

The pivot — drone → courtside gimbal (and a lesson)

Here’s where the project hit its biggest wall, and I want to log it honestly because the recovery taught me more than any milestone.

I was about to spec a drone. Then I actually researched drone law in Qatar and found out it’s one of the strictest regimes in the world: every single flight needs a QCAA permit (owning a drone gives you no right to fly it), and there’s a privacy law (Penal Code Art. 333) against filming people without consent, penalties up to two years. For a system whose whole job is filming school matches full of players and spectators, that’s not a paperwork hurdle, it’s a wall. My original picture a drone autonomously filming matches was effectively dead.

The lesson, written down so I don’t forget it: research the constraints of the real world before you fall in love with a plan. I’d validated the software to machine precision, but I almost skipped checking whether the deployment was even legal. Check the boring stuff first.

So I swapped the drone for a 3-DOF gimbal on a rail: a motorised camera mount (pan / tilt / roll) that slides along a track, parked courtside. No permit. Same filming-consent terms my existing fixed cameras already navigate. And it runs every match, not the one-off a permitted drone flight would’ve been. It’s more deployable than the drone ever was.

A gimbal is also a categorically real difference from just pointing a camera, for one optical reason that isn’t arguable: a fixed camera can only ever crop the pixels it already has, but a gimbal physically moves the lens real parallax, a real push-in that changes perspective, footage that simply doesn’t exist in a static feed. The human directs the intent (“orbit that player,” “push in”) and the system, which understands the scene, executes the move. That’s the thing a fixed camera can’t do, and it survived the pivot completely intact.

M9 — the gimbal’s brain (software)

Stardance just opened a hardware track, but this milestone was deliberately software: adapt the system to the gimbal before the parts arrive, so the maths is proven when the hardware lands.

The beautiful part: because I’d kept the architecture cleanly separated for nine milestones, the drone→gimbal pivot touched exactly one layer. The gesture engine, the scene tracking, the intent commands, the flight-path engine, the live bridge all unchanged. The only new code is a converter that takes an ideal 3D camera pose and works out what the gimbal can physically do with it: pan/tilt/roll angles to aim, plus a position along the rail.

And it stays honest, which is the whole point. A gimbal at a fixed pivot can rotate perfectly but can’t translate so a true orbit (circling a subject) is impossible without the camera leaving its rail. The converter proves this with numbers instead of faking it: a follow shot aims with 0.00° error and zero positional gap (the rig does it cleanly), while an attempted orbit still aims perfectly but reports a 9.05-unit gap, flagged out-of-reach on every frame the system refuses to pretend it can do something the hardware can’t.

Honest problems that will probably come up: this is geometry on a perfect simulator. The real gimbal will have motor speed limits, inertia, and backlash, it won’t snap to an angle instantly. That’s the hardware phase’s problem, and I’m not pretending the clean sim is the real rig.

Up next: the glove parts are shipping. When they land, the build goes physical. breadboard, sensors, solder. Then the gimbal it is

Quick one today. I needed multi-file uploads on meeting days, you should be able to attach several photos to a single meeting requirement, not just one. Turns out I’d already solved this exact problem for deadline proof files a while back. So instead of reinventing it, I basically reused the pattern I’d already built: same upload handling, same storage path, same way of listing and attaching multiple files to one thing.

Honestly the satisfying part is that this was easy because of how I set things up earlier. Past me put the upload wiring in one shared place instead of copy-pasting it per feature, so extending it from “deadlines can have many files” to “meetings can too” was a small change, not a rewrite. It’s a nice reminder that the boring structural decisions pay off later. The work you do once to make the next change cheap is invisible until the moment it saves you.

Onto the next thing. Still want to wire up the real Google Drive connector (the stub’s already in place for when our mentors share a folder), add a proper compliance summary view, and let people delete individual files.

Devlog 1
Built a strategy engine from scratch this stretch. The interesting part wasn’t the code, it was figuring out what the game actually rewards, because once I read the manual carefully the “obvious” strategy turned out to be wrong.

The 2026 game has two goals (suppression and extinguisher), both worth 1 point per ball. Looks symmetric. It isn’t. Only the suppression goal gets multiplied by your end-game climb, and the climb multiplier is shared across all three robots on your alliance (three robots at the top zone multiply your combined suppression total by 1.9). The extinguisher, meanwhile, is a shared global pot that all six robots including your opponents feed and all six receive. So feeding the extinguisher barely helps you win. The whole tool is built around surfacing that asymmetry, because it’s the thing that’s easy to get wrong by just reading the point values.
How it’s built: there’s a pure scoring engine (no UI, no network, no AI, just math) that I can actually test, sitting behind a React frontend that just renders its results. That separation meant I could later do a full visual redesign without touching a single line of the math. The engine composes a cycle (travel, intake, travel, deposit), reserves time for the climb, floors the number of full cycles that fit in 150 seconds, applies accuracy and reliability, and then runs the real scoring formula with the climb multiplier. Everything’s shown as arithmetic, not just a final number, so nobody has to take it on faith.
The trust gate is the part I’m most deliberate about. Before any result is shown as real, you pass a “verify and lock” screen that lists every scoring number in plain language next to what it means. Editing any value automatically un-verifies the config, and unverified results get stamped “do not trust” everywhere. This is because the entire engine is only as correct as the numbers I typed in from the manual, so one transcription error has to be catchable, not silent.

Two features I’m happy with. There’s an alliance screen where you change each robot’s climb zone and watch the shared multiplier move live, it makes the “coordinate your climbs” insight visible instead of theoretical (in my worked example, sharing the multiplier across the alliance instead of each robot climbing for only itself is worth about 94 points). And there’s an archetype comparison built specifically to settle a debate on my team: some people thought a storage bot feeding human players was a good plan. So I modeled three strategies through the same engine with a live slider for human-player speed. You can crank the human feed rate past anything physically plausible and the feeder strategy still loses, because its points are unmultiplied and shared. That’s a much better way to win an argument than just asserting it.

It’s a free static site on Cloudflare, 58 tests, no backend. Honest limitation I’m keeping visible: it models a robot in a vacuum, no defense, no congestion, no ball scarcity, so it’s for relative comparison and the two big decisions (climb or not, what to improve), not absolute predictions. Feed it measured cycle times from practice and it gets sharper, so thats what I’ll try to implement in the coming devlogs.

Devlog
Went from empty repo to a deployed, working app this session. Here’s what’s actually in it.
The core is a calendar. I mark which days are meeting days (with a bulk option so I can set “every Tuesday and Thursday” in one go instead of clicking 40 times). The second I mark a day, it snapshots the current requirement checklist onto that day, things like attendance, robot accomplishments, build needs, performance goals, photos of sketches. I built it as a snapshot on purpose so that editing the requirements later doesn’t reach back and rewrite old meetings.
On each meeting day you can take attendance against the full 21-person roster, log accomplishments and build needs and failures (each tagged to a subsystem like drivetrain/shooter/climber), and upload photos and docs. Files go to Cloudflare R2.
Then the part that makes it more than a folder: a compliance engine that derives a red/amber/green status for every day and every deadline. Green if all the compulsory stuff is in, amber if it’s recent and still in progress, red if a past meeting is missing something required. All of that rolls up into a dashboard that opens with one big team status plus a “needs attention” list of everything currently red, so you can see in two seconds where the team is behind. It also tracks standalone deadlines separate from meetings (our social media challenges have their own due dates and actually score competition points), and those go red when overdue.
There’s a search/browse view across everything logged, an admin area for managing the roster and editing what counts as compulsory, and ZIP export of any day’s media plus a summary.
Stack is all Cloudflare free tier: React + Vite frontend on Pages, a TypeScript Hono API on Workers, D1 (SQLite) for data, R2 for files, Supabase magic-link for login. 71 tests on the worker covering the compliance logic.
Two things I’m glad I built in. A hard free-tier guard: files cap at 10MB and the worker refuses any upload that’d push total storage past 8GB, so a school project can never surprise me with a bill. And a clean separation between the UI and all the network/auth wiring, which let me drop in the full Team Qatar redesign without touching how anything works.
This is v1, there’s a Google Drive connector already stubbed in for when our mentors share a folder, and a lot more I want to add. More to come.

Hi I’m Aarav Sharma and I want to direct a drone with my hands, not just piloting but actual direction.

Introducing AirLine: direct a drone with your hands, don’t pilot it. Most gesture drones map your hand to a flight stick (tilt to bank, raise to climb) — you become the joystick. AirLine instead reads cinematic intent (“follow that player,” “orbit the subject”) and figures out the flight itself, because it understands the scene. It’s a branch off my capstone SideLine (an AI sports-analytics system that already tracks “the player with the ball”), reusing its vision core untouched. Software first, glove I build myself next, drone last.

Devlog:

M1: AirLine runs SideLine’s tracker through a clean seam, vision core untouched. ~19 FPS.
M2: Lock onto one subject. Found track IDs fragment — 293/540 frames “lost.” Quantified the re-ID problem on footage, not a $400 drone.
M3: Virtual camera follows like an operated shot, drifts to wide when the target’s lost. First time it looked real.
M4: Webcam gestures (MediaPipe) — but it conflicts with my vision stack. Setup stopped instead of breaking it. Best decision of the day.
M5: Quarantined gestures in their own environment. First real-hand numbers: mostly 10/10 after fixing bugs unit tests missed.
M6: Two-process live system — my hand directs the shot in real time. ~297ms latency, only 35ms of it transport.
M7: First 3D camera move: orbit on a tiltable plane, proven by geometric invariants to machine precision (~4e-16).
M8: Added push-in, pull-out, dolly. Full shot vocabulary done. 146 tests, vision core never touched.

Next: hardware actually building the gesture glove by hand and integrating a drone

Hi I’m Aarav Sharma, I started this before Stardance, so this first devlog covers everything built so far (about 6 hours of work) in one go. Sideline is an AI system that films a school football or basketball match from a single fixed camera and turns that one recording into three different things: tactical analytics for coaches, event highlight reels for the school socials, and a personal highlight clip for every player, not just the goal-scorers. It runs entirely on a local laptop with no subscriptions, which matters because the commercial equivalents (Veo, Pixellot) cost hundreds up front plus monthly fees, putting them out of reach for a normal school.
The computer vision (both football and basketball). The core is one shared pipeline that detects players and the ball, tracks them across the match, works out which team each player is on, and maps the camera view onto real court coordinates so distances and positions actually mean something in metres. Getting each piece trustworthy was the bulk of the time, and a lot of it was fighting genuinely hard problems. The basketball ball tracker kept locking onto players’ heads (round, ball-sized, and constantly held right next to the ball during a shot), and I had to prove that no shape or size rule could ever separate them before fixing it with a small appearance classifier I trained on a few thousand hand-sorted image crops (head rejection went from hopeless to 98.5%). Team detection on similar kits kept collapsing into one cluster until I switched to appearance embeddings, which also caught a possession stat that was confidently pointing at the wrong team entirely.
The three deliverables. Coach analytics come out as a one-page report plus an annotated tactical video (heatmaps, distance covered, possession, formation, territory), with every number honestly labelled as either validated or derived. Event highlights are auto-detected and ranked so the best moments float to the top instead of flooding whoever is editing. Player highlights are built to be inclusive by construction: every player who steps on the court gets footage, using their on-ball moments where they have them, which is the part no commercial product bothers with and the part a school actually cares about.
The app. All of that is wrapped in a working local web app, “Sideline, Match Studio”, with a dark cinematic interface a non-technical teacher can run start to finish: upload a match, click the four court corners on a freeze-frame, pick which deliverables they want, and download the results. The backend is a FastAPI server that runs the heavy AI as background jobs (a full match takes around 3 hours, so it processes while you walk away and can survive a restart), and it wraps my existing pipeline scripts rather than rewriting them. The whole thing is tested end to end with 62 passing checks, and I have already stress-tested it on a full 47-minute match to see what breaks at real scale.
Next stop is real deployment at my school, which is the one thing I cannot fully validate until I have footage from our own courts and teams.