Healthcare · optometry · Wichita Family Vision · Live 2026-08-07

Front desk knowledge base for an eye clinic: anyone at the desk finds the right answer in one search, without pulling a manager away.

The rules lived in 15 spreadsheet tabs and one manager's head. Now anyone at the desk, new or experienced, looks up the answer in the 20 seconds a caller gives you, and the managers keep it current themselves.

~200hrs/yr of interruptions off the office manager's desk About 4 questions a day that used to cost 10 minutes of digging or a manager's attention, now one search, over 250 working days.

35pages of protocol, plus a 41-row price grid, maintained by the staff themselves

A question on a live call, answered in seconds. Sample page and rule, screens simplified.

The front desk knowledge base home screen: a search box, quick-pick chips, and the four decision tools — The home screen the front desk sees. Clinic logo blurred; everything else is the live app.

At a glance

Client: Wichita Family Vision, an independent optometry practice in Wichita, Kansas.
Who uses it: The front desk and 2 office managers, daily since August 2026.
Shipped: Live 2026-08-07. About 6 weeks from scope to live.
Stack: Supabase
PostgreSQL with row-level security
Google OAuth
Vanilla JS PWA
Vercel
GitHub Actions
DOMPurify
Claude Code
Compliance: Built for a HIPAA-covered clinic with zero patient data in it by design: protocols and prices only, sign-in locked to the clinic's domain, a business associate agreement in force with the practice.
Cost to run: $0 a month to host. The clinic pays a small monthly retainer for the editing feature and a pass-through for the database tier.
My role: I built it: the content model from the clinic's front-desk documents, the 35 pages and 4 decision tools, in-app editing with revision history, and the tests. A second engineer ran the pre-merge security review and the deployment.

What I built

The build

An installable web app on every front desk device: 35 protocol pages in 7 sections, a live 41-row price grid, and a report-an-issue loop that gets fixed the same day.
4 decision tools that force the buried exceptions open: which doctors a patient can see, the right price with prompt-pay, whether to collect or bill a refraction, and how urgent a symptom is.
In-app editing for 2 named managers, with revision history in plain English and one-click restore. No developer in the loop for a content change.
Google sign-in restricted to the clinic's domain, row-level security on every table, sanitized rendering that fails closed, a monthly export as the backup.

In-app editing with revision history — Managers edit in the browser; every change is kept and can be restored.

The provider eligibility decision tool — The eligibility tool: answer 4 questions, get the doctors this patient can see.

The knowledge base installed on a tablet — Installed on the front desk tablet as an app.

What changed

Before and after

Before

By hand

Where the rules live15 spreadsheet tabs, a protocol doc, a rulebook, one person's memory

An unusual questionInterrupt a manager

When someone leavesTheir know-how leaves with them

Changing a ruleEmail the developer, wait

Cost to runManager time

After

The system

Where the rules liveOne searchable app, 35 pages, 4 tools

An unusual questionSearch, answer in under a minute

When someone leavesIt stays in the app

Changing a ruleEdit in the browser, history kept

Cost to run$0 a month in hosting

Where the numbers come from. About 4 interrupting questions a day at 10 minutes each, over 250 working days, gives roughly 200 hours a year. The office manager agreed the working was fair.

For engineers

How it's built

Architecture: Static PWA on Vercel reading page content, prices, and revisions from Supabase over the REST API. Editors are a Postgres table; RLS gives everyone read and 2 named emails write. Rendering sanitizes at read time, not only at save, so a REST write can never reach a reader unfiltered.
Where it runs: Vercel (app), Supabase free tier (content, auth, revisions), Google Workspace sign-in locked to the clinic's domain. Installed as a PWA on the front desk iPad and PCs.
Tests and evals: 21 regression tests plus a DOM-free sync-logic suite (31 assertions) covering restore, refresh, and the offline editor guard. Every test was written from a bug we actually hit.
Cost and latency: $0 a month to host. The clinic pays a small monthly retainer for the editing feature and a pass-through for the database tier.
Guardrails: A pre-merge security review caught 2 cross-site-scripting holes: page HTML was sanitized on save but not on render, and the editor parsed pasted HTML into the live DOM before cleaning it. Both fixed by sanitizing at render, failing closed. Monthly JSON export is the backup because the free tier keeps none.
The tradeoff we chose: Why this way and not the other
We built a plain PWA with search instead of the AI assistant layer the first scope had. Search on 35 well-structured pages answers the front desk's question faster than a chat box, costs nothing to run, and never invents a rule. The assistant is on the roadmap only if search ever fails a real staff question.
Code: github.com/alecstephens3-stack/supabase-team-knowledge-base
The pattern, rebuilt without any clinic content: RLS, domain-gated auth, revision history, sanitizer, offline sync.

The pattern on GitHub

In their words

“This is highly valuable, both in the short term and long term. It's already saving a lot of time.”

Jill Romines, Front Office Manager, Wichita Family Vision