Desk Wellness Pack

What Smart Stretch actually is
 

This extension does not use AI or machine learning. It uses a lightweight decision layer that reads the last 8 interactions and maps them to one of four session types:

async function chooseSmartSessionType() {

  const recent = history.slice(-8);

  const recentSkipped  = recent.filter(e => e.type === 'skipped').length;

  const recentSnoozed  = recent.filter(e => e.type === 'snoozed').length;

  const recentCompleted = recent.filter(e => e.type === 'completed').length;

 

  if (recentSkipped + recentSnoozed >= 4) return 'quick_reset';

  if (recentSkipped + recentSnoozed >= 2) return 'gentle_stretch';

  if (recentCompleted >= 5 && recentSkipped === 0) return 'full_reset';

  return 'standard_stretch';

}
 

The four session types — quick_reset (30s), gentle_stretch (45s), standard_stretch (60s), full_reset (90s) — each carry their own title, exercise name, and guidance copy. The session chosen by the background is stored to local storage. When the stretch screen opens, it reads and applies it.

This was the moment the product stopped feeling like it was replaying the same interruption. It felt more intentional — more honest about what the user's recent behaviour had been.


 

 

Adding Water Reminder: designing a second module without doubling the complexity
 

After shipping Smart Stretch, the most natural next step was hydration. Dehydration and lack of movement often go together at a desk — and they share the same root cause: work has your full attention, and your body doesn't.
 

The design challenge was not 'what should the water screen look like.' It was:

How do you add a second independent module to an extension that already has a functioning system, without introducing coupling, complexity, or visual noise?
 

The architectural decision: genuinely independent timers

The temptation was to add water as a sub-feature of stretch. I chose instead to treat it as a separate module: its own alarm, its own state keys, its own license, its own badge logic, its own UI section in the popup.

const WATER_ALARM_NAME         = 'waterAlarm';

const WATER_MEETING_CHECK_ALARM = 'waterMeetingCheckAlarm';

const WATER_POST_MEETING_ALARM  = 'waterPostMeetingAlarm';

const WATER_POST_MEETING_BUFFER_MINUTES = 5;

Both modules share background.js and the checkCalendar() function, but their state, alarms, and license tokens are entirely separate. A user can stop stretch without affecting water. They can buy Water Pro without touching Stretch Pro. The modules are independent by design.

 

One-shot vs repeating alarms

A key design decision for water: unlike stretch, which uses a repeating alarm, water uses a one-shot alarm rescheduled after each interaction. When the user logs a glass or skips, the next reminder is scheduled fresh from that moment. This means the rhythm adapts naturally to when the user actually drinks, not to an abstract clock.
 

// After logging a glass — next reminder from now

if (request.type === 'logGlass') {

  const newCount = Number(data.waterGlassesToday || 0) + 1;

  await setLocal({ waterGlassesToday: newCount });

  scheduleWaterAlarm(ws.waterInterval); // fresh from now

  sendResponse({ ok: true, waterGlassesToday: newCount });

}

 

The animated glass: making progress visible

The water screen was designed around a single emotional idea: the satisfaction of watching something fill up. The animated glass with a CSS wave surface, rising bubbles, and smooth fill transition gives users a moment of visible progress with every glass logged. It is small, but it makes the act of drinking water feel rewarding rather than administrative.
 

/* water.html — glass fill animates to match glasses / goal */

.water-fill {

  transition: height 0.6s cubic-bezier(0.34, 1.56, 0.64, 1);

  background: linear-gradient(180deg,

    rgba(90,169,255,0.55),

    rgba(61,143,224,0.75));

}

 

function renderGlass() {

  const pct = Math.min(glasses / goal, 1);

  waterFill.style.height = Math.max(pct * 96, 3) + '%';

}

 

The next reminder countdown

A subtle but important detail: the water screen shows a live countdown to the next reminder. This required aligning the water screen's own countdown with the popup's timer display. Both read from the same waterStartTime value stored when the alarm is scheduled, so they always agree.
 

// water.js — startReminderCountdown()

const render = () => {

  const totalMs   = intervalMinutes * 60 * 1000;

  const elapsed   = Date.now() - startTime;

  const remaining = totalMs - elapsed;

  nextReminderTime.textContent = formatRemaining(remaining);

};

render();

timerInterval = setInterval(render, 1000);

 

 

Meeting detection: one calendar integration, two modules
 

Pro users for either module can enable Skip during meetings. Both modules reuse the same checkCalendar() function, a single Google Calendar FreeBusy API call that returns only a busy/free status for the next 90 minutes.
 

A non-obvious MV3 constraint: where OAuth can run

Chrome's Manifest V3 has a strict rule: chrome.identity.getAuthToken({ interactive: true }) silently fails when called from a service worker or from the extension popup (which closes on focus loss). The only place interactive OAuth works reliably is a dedicated popup window.

​

// popup.js — open a dedicated window for auth

chrome.windows.create({

  url: chrome.runtime.getURL('oauth.html'),

  type: 'popup',

  width: 380,

  height: 260,

  focused: true

});

 

// oauth.js — gets the token, sends result back

chrome.identity.getAuthToken({ interactive: true }, (token) => {

  chrome.runtime.sendMessage({

    type: 'calendarAuthResult',

    success: !!token

  });

});
 

This architecture applies to both modules, the same OAuth window is reused for both stretch and water calendar integration. One shared token, two separate calendarEnabled flags.

 

Water meeting state machine

When a water alarm fires and a meeting is detected, the module enters a three-state flow identical in structure to stretch:

1. ALARM fires → check calendar → meeting detected → store waterMeetingActive, schedule waterMeetingCheckAlarm

2. MEETING_CHECK fires → meeting ended → store waterPostMeetingStartTime, schedule waterPostMeetingAlarm, badge switches from MTG to 💧

3. POST_MEETING fires → open water window, reschedule normal alarm
    

// Meeting ended — switch badge from MTG to 💧

await setLocal({

  waterMeetingActive: false,

  waterMeetingEndTime: null,

  waterPostMeetingStartTime: Date.now()

});

chrome.alarms.create(WATER_POST_MEETING_ALARM, {

  delayInMinutes: WATER_POST_MEETING_BUFFER_MINUTES

});

startBadgeCountdown(); // badge loop now shows 💧, not MTG
 

The popup reflects this state with a live message: 'Meeting ended, water break starting in' with a 5-minute countdown. When the buffer expires, the water window opens with a fresh waterStartTime, and the normal alarm is rescheduled.


 

 

Badge logic: one icon, multiple meanings
 

The toolbar badge is the only persistent visual signal users see between reminders. Getting its state machine right was important, with two modules active simultaneously, it needed clear priority rules.

// Priority order inside startBadgeCountdown()

 

// 1. Stretch shown → clear badge

if (runtime.stretchReminderState === 'shown') { clearBadge(); return; }

 

// 2. Stretch in meeting → MTG (blue)

if (runtime.stretchReminderState === 'in_meeting') { setBadgeMeeting(); return; }

 

// 3. Stretch post-meeting → red countdown

if (runtime.stretchReminderState === 'post_meeting') { ... return; }

 

// 4. Stretch running → green/yellow/red countdown

if (data.interval && data.startTime) { /* colour-coded minutes */ return; }

 

// 5. No stretch — check water

if (waterData.waterMeetingActive) { setBadgeMeeting(); return; }

if (waterData.waterEnabled && waterData.waterStartTime) {

  chrome.action.setBadgeBackgroundColor({ color: '#5aa9ff' });

  chrome.action.setBadgeText({ text: '💧' });

  return;

}

clearBadge();
 

A subtle fix worth noting: when stretch stops, stopTimer() checks whether water is still running before killing the badge countdown. If water is active, it calls startBadgeCountdown() instead of stopBadgeCountdown(), so the 💧 reappears immediately rather than requiring a full popup refresh.

Pro licensing: stateless, secure, no database
 

Both Pro tiers, Stretch (€3) and Water (€5), use the same stateless HMAC-SHA256 architecture. The backend issues a license token by hashing a module prefix with the installation ID. Verification is a comparison of hashes. No user records, no database, no subscriptions.
 

// verify-water-payment.js — issue water license token

const waterLicenseToken = crypto

  .createHmac('sha256', process.env.LICENSE_SECRET)

  .update('water:' + installationId)

  .digest('hex');

 

// The 'water:' prefix ensures the token is

// cryptographically distinct from the stretch token,

// even though both use the same LICENSE_SECRET.
 

The prefix matters. Without it, a user who bought Stretch Pro could reuse the same token to unlock Water Pro. The HMAC prefix makes the two tokens mathematically independent.

License verification is cached in memory for 1 hour and trusted from storage for 24 hours. After 24 hours, the background silently re-verifies against the server. If the network is unavailable, the extension fails open,  a user with a valid cached token is never locked out.
 

if (json.valid) {

  _waterLicenseCache = { isPro: true };

} else {

  _waterLicenseCache = { isPro: false };

}

} catch (e) {

  // Network error — fail open. Offline users stay unlocked.

  console.warn('License verify error, trusting cached:', e.message);

  _waterLicenseCache = { isPro: true };

}

 

​
 

Manifest V3: platform constraints as product decisions
 

Several non-obvious MV3 constraints shaped the product architecture directly. Each one was discovered through testing, not documentation.
 

1. Inline onclick blocked by CSP

Chrome's Content Security Policy for extensions blocks inline event handlers. The tab switcher between Stretch and Water initially used onclick="switchTab('water')" directly in HTML, and silently failed. The fix was to wire all event handlers in JavaScript using addEventListener.
 

2. Service worker audio

Audio playback from a service worker is unreliable in MV3. Sound plays inside stretch.js and water.js, never from background.js. The service worker's alarm handler opens the screen, which then handles its own audio.
 

3. fetch() without timeout stalls service workers

An uncompleted fetch() inside an alarm handler can prevent the service worker from sleeping, causing memory and CPU issues. Every backend call uses a 5-second fetchWithTimeout() wrapper with an AbortController.
 

function fetchWithTimeout(url, options = {}, timeoutMs = 5000) {

  const controller = new AbortController();

  const timeoutId = setTimeout(

    () => controller.abort(), timeoutMs

  );

  return fetch(url, { ...options, signal: controller.signal })

    .finally(() => clearTimeout(timeoutId));

}

​

 

What makes this product strong
 

The extension is intentionally simple on the surface. Under that simplicity, it demonstrates product thinking in the areas that matter most:

 

1. Reliability over novelty

The most important feature is trust. If the timer, badge, and popup disagree with each other, the habit breaks — and users stop relying on the tool. Every architectural decision was made to prevent that disagreement.
 

2. Clear ownership of state

The background owns both reminder cycles. Temporary surfaces only reflect them. This is a constraint that makes the product more honest and easier to reason about.

3. Behaviourally correct controls

Snooze is temporary. Skip returns users to their preferred rhythm. Log a glass and the next reminder starts fresh. These are small decisions that make the product feel rational.

 

4. Independent modules, shared engine

Stretch and water are genuinely independent, separate alarms, state, licenses, and UI. They happen to share a background engine and a popup. That structure made it possible to add water without refactoring stretch.

​

5. Honest intelligence

'Smart Stretch' uses a lightweight decision layer, not AI. The session type is determined by a simple rule tree applied to the last 8 interactions. It is transparent, lightweight, and does exactly what it says.

​

6. Platform-aware implementation

OAuth in a dedicated window. Event listeners instead of inline handlers. One-shot alarms for water. fetch() with a hard timeout. These are not engineering niceties — they are product decisions made visible by real failures during testing.

 

​

​

Current feature set

​

SMART STRETCH

• Persistent background alarm, works whether popup is open or closed

• Live badge countdown, green, yellow, red by minutes remaining

• Four adaptive session types driven by recent behaviour

• Snooze (5 min) and Skip (returns to preferred interval)

• Guided stretch screen with progress ring, session-aware instructions, completion state

• Weekly stats, this week and last week side by side

• Sound toggle for a gentle chime on screen open

• Pro: Google Calendar meeting detection, 5-minute post-meeting buffer

​
 

WATER REMINDER

• Independent background timer — separate from stretch in every way

• Animated glass that fills as glasses are logged

• Daily glass counter with dot progress tracker and live next-reminder countdown

• One-shot alarm rescheduled from the moment of each interaction

• Sound toggle with dedicated water chime

• Badge shows 💧 when water is active, MTG when meeting is in progress

• Pro: custom daily glass goal, Google Calendar meeting detection

​
 

SHARED INFRASTRUCTURE

• Stateless HMAC-SHA256 licensing, two independent tokens, one shared secret

• Serverless Vercel backend, Stripe checkout and license issuance

• Shared Google Calendar FreeBusy integration, one OAuth token, two modules

• CSP-compliant popup, event listeners only, no inline handlers

• Service worker recovery, both modules restore from storage on every wake
  
   

 

What I learned

This project reinforced a principle that matters across every scale of product:

 

Small products still need systems thinking.

Even a lightweight extension can fail if the state model is unclear, the mental model is inconsistent, or the UI does not reflect reality. The most valuable work here was not visual polish.

It was aligning user expectations, background logic, surface behaviour, and product trust, across two modules, two payment flows, and one shared engine. That is what turned a timer experiment into a product case worth writing about.

 

 

What's next

The product ships as two modules. The architecture supports more. Potential additions that stay true to the product's philosophy:

• Posture prompts. a third independent reminder module

• Time-of-day stretch suggestions based on hourly patterns

• Expanded exercise rotation with sessionStorage to prevent repetition

• Accessibility modes. reduced motion, visual-only reminders

• User-configurable Smart Stretch thresholds

 

The goal is not feature growth. It is sustainable, low-friction behaviour support that earns a permanent place in someone's workday.

 

 

Final reflection

This project started with a personal frustration: working until discomfort was the first signal I had ignored my body too long.

What it became is a compact but thoughtful dual-module product. Not just a Chrome extension.

 

A small system designed to help people work more sustainably, without demanding more attention from them than necessary.

​