Charlie HarmanCH3
Project indexPrivate system

Case study · 2026

Howie Helper

A phone-first scheduling app I built and host for the pizza store where I'm an assistant manager. My GM uses it to build and publish the weekly schedule.

No public source or live link
One store
a handful of people, invite only
Offline
local copy on the phone, writes queued until reconnect
~2,500
unit and component tests

01 · Overview

Role
Solo build, AI-assisted with Claude Code: design, architecture, hosting
Status
In use at my store · schedule only
Privacy
Private system

From real constraint
to working system.

The challenge

Our weekly schedule lived in a shared spreadsheet that's hard to read and edit on a phone, and crew availability and time-off requests came in through texts. I wanted one place on my phone where the schedule gets built, checked against availability, and published.

The response

I built an installable web app, starting with a static HTML prototype in June 2026 and moving to React, TypeScript and a self-hosted Supabase backend in July. Today the store uses only the schedule. I also built other tools (inventory, nightly numbers, dough planning, drawer cash), but they're hidden or unused at the store.

  • React
  • TypeScript
  • PWA
  • PowerSync
  • Supabase
  • PostgreSQL
  • Docker
  • Cloudflare Tunnel
  • Vitest
Three phones showing Howie Helper's crew schedule view, the manager's draft week with availability flags, and an availability request form.
Crew view, manager draft, and availability requestMockups rendered from the real app with made-up crew and a demo store. No real schedules or names.

02 · Build

What the system needed.

Howie Helper features and engineering decisions

01

Schedule

Draft, check, publish

Managers edit a private draft of the week while the crew only see the published version. Availability and time-off requests show on the draft grid, so conflicts are visible before anything goes out.

  • Weekly grid editor with a draft/publish gate
  • Crew availability and time-off requests overlaid on the draft
  • Copy-out to the owners' spreadsheet, plus PNG/PDF export
02

Offline first

Works when the store Wi-Fi doesn't

Each phone keeps a local SQLite copy of its store's data through PowerSync. Writes queue while offline and sync when the connection returns, so IDs and write rules have to survive retries. For example, the cash log is append-only.

  • Local SQLite replica with a queued write path
  • Separate upload queue for photo attachments
  • Prompt-to-update banner, because installed copies kept running old versions after deploys
03

Access control

Rules in the database, not just the UI

Every table has Postgres row-level security scoped to a store, with platform admins and a 7-rank member ladder on top. I checked the rules by impersonating real accounts before a second store's GM was given access.

  • Per-store row-level security on every table
  • Invite-code signup and role-based tool visibility per store
  • API rate limits tuned per endpoint, because a rate-limit error on sign-in would end the session and clear the offline queue
04

Running it

Self-hosted on my homelab

The backend (Postgres, auth, REST API, storage, sync) runs in Docker on my homelab and is exposed through a Cloudflare Tunnel. Deploys are a script I run by hand, and GitHub Actions type-checks and tests every PR.

  • Self-hosted Supabase and PowerSync in Docker
  • 32 SQL migrations and SQL scripts that check the access rules
  • CI for type-checking and tests; deploys are manual

03 · System

Boundaries before boxes.

Sanitized system architecture

Conceptual architecturesanitized / not to scale
  1. 01Installable React PWA
  2. 02PowerSync local replica
  3. 03Supabase auth & API
  4. 04PostgreSQL with RLS
  5. 05Homelab via Cloudflare Tunnel
This intentionally high-level view communicates system boundaries without exposing infrastructure details.

04 · Views

Designed representations.

Desktop view of the weekly schedule editor with shifts by role, hours, totals, and highlighted availability conflicts.
Schedule editor on a wide screenThe full draft week with hours per shift, weekly totals, and availability flags from crew requests.
Phone view of the draft schedule with a red-outlined conflict and an amber-outlined warning.
Manager's draft weekOne availability conflict (red) and one warning (amber) flagged before anything is published.
Phone view of the published schedule with the viewer's row pinned at the top.
Crew viewA crew member sees only the published week, with their own row pinned at the top.
Phone form for requesting availability changes by day, with open, close, any, and off options.
Availability requestCrew request an availability change or time off, and it goes to the GM for approval.
Phone view with a notice that three unsaved items are waiting on the device until they sync.
Unsynced changes stay on the phoneEdits made offline wait on the device, and the app counts them until they sync.

05 · Outcomes

A stronger operating baseline.

  1. 01

    The store's weekly schedule is built and published in the app.

  2. 02

    I've worked through real offline sync, access control, and self-hosting problems for a small group of real users.

  3. 03

    Other tools exist but aren't in use, and I'm keeping the app focused on scheduling for now.