Solo product build · Product strategy, UX design, systems architecture, front-end dev · 2026
The order of agenda items shouldn't dictate how long you spend on something. Leverage A.I. to appropriately weight agenda topics.
- Problem
- Meeting timers split the clock evenly and assume they own the room, but the meeting moves, a client's Zoom instead of your Teams, an auditorium instead of a huddle room, a shared window instead of the agenda tab.
- Solution
- An importance-and-complexity weighting algorithm allocates time by topic, and the same engine surfaces wherever the meeting goes, as a web app, a focused start screen, and a draggable Chrome overlay that rides on top of any other tab.
- Stack
- Live deterministic allocation algorithm, dual-provider client-side OAuth (Google + Microsoft), and a three-layer Chrome extension with a shadow DOM overlay and cross-tab state sync. No backend, no accounts, no stored meeting data.
Most meeting timers split the clock evenly and call it a day. MoveOn reads an agenda — typed, pasted, or imported from Google Calendar or Outlook — weights each topic by importance and complexity, and allocates time accordingly. When a topic's time runs out, a visual and audible signal tells the room to move on. The social cost of cutting someone off moves from the facilitator to the tool. No backend. No accounts. No stored meeting data. By design.
4 surfaces
iOS, web, Chrome Ext. apps
AI-based
topic weighting
0
servers holding your data
Meet the meeting where it is
Most timing tools demand that you come to them. They live inside one video platform, so the moment a meeting changes shape they stop being useful. The client hosts on Zoom when your team runs on Teams. The session that started in a small room gets moved to the auditorium, where a phone on the table no longer cuts it and a browser on the projector does. You begin with the agenda shared on screen, then need to swap to another window to walk through a document, and the timer vanishes with the tab. MoveOn is built to follow the meeting instead of dictating it. The web app runs anywhere a browser does, independent of the video platform. On a phone or tablet it works for the room you're sitting in. When the meeting needs a second window, the Chrome extension lifts the timer out of the tab and floats it over whatever you share next, so the clock stays in view no matter what's on the screen underneath.
Predict importance and attribute time accordingly.
A fixed meeting duration has to be distributed across topics of genuinely different weight, while reserving welcome and wrap-up slots, respecting a minimum time per topic, and reacting instantly when someone adds, removes, or reorders an item mid-setup. That is not a percentage split. It is a real allocation algorithm, and it has to recompute live as the setup screen changes — deterministic, idempotent, and fast enough to feel instant. Everything else in the product is interface. The weighting is the product.
“The weighting algorithm is the product. Everything else is interface.”
Privacy as architecture
The no-backend rule came first and shaped everything downstream. Meeting state lives in localStorage. Calendar tokens are session-only. The only server component is an anonymous edge counter that increments a public number. This is not a shortcut. It is a privacy position taken as architecture, and it is why there is no password reset, no GDPR consent wall, and no onboarding flow standing between a user and their first timed meeting.
The extension is a distributed system
The Chrome extension turned out to be a distributed-systems problem wearing a plugin costume. It has to read live meeting state from the React app, display a draggable floating overlay on any other tab, and relay control commands back into the app without coupling to its internals. The solution is three layers: a MAIN-world content script polling shared state, a service worker brokering state and commands, and a shadow DOM overlay running its own second-by-second countdown from raw timing data. Along the way: chrome.storage.session, the natural fit for ephemeral shared state, is not available to content scripts in Manifest V3, forcing a deliberate fallback to chrome.storage.local.
A shadow DOM means the host page's CSS variables don't inherit. Every design token in the overlay had to be hardcoded from the same source values as the app, so green means exactly the same green in the extension as in the product. Not approximately consistent. Exactly consistent.
Ambient awareness, not nags
The favicon changes color using the actual brand tokens — green above two minutes, amber under two, red at expiry — rendered as inline SVG data URLs swapped onto the page's icon element. The tab title counts down while the user is elsewhere. These are peripheral signals, built to be glanced at, not obeyed.
Outcomes
A live weighting algorithm that allocates meeting time by topic importance and complexity and recomputes instantly on every edit. Dual-provider calendar OAuth running entirely client-side. A three-layer Chrome extension with a drag-and-drop overlay, cross-tab state sync, and persisted widget position across browser restarts — packaged and submission-ready (not yet submitted). A landing page, a focused start screen, a privacy page, and a Stripe monetization layer gated behind environment variables, all built solo. Live at moveonapp.work.
Next case study
Solo product build
WatchlistPro