Building an innovative, all-encompassing management platform for retail and hospitality.

Most workforce SaaS is built for office workers — long-form, dense, click-heavy. Teemie's users are on the shop floor, behind the bar, on a delivery route. They share devices. They work different hours. Many don't speak English as a first language. They don't read manuals. They use the product in 30-second windows between tasks.

Glance-able information over complete information. Predictable interactions over clever ones. Fault tolerance over efficiency. Specific design choices that ran through every screen: large tap targets on mobile, GPS clock-in over manual entry (clock-in failure is a wage dispute waiting to happen), high-contrast type, no decorative motion, every primary action one tap from the home screen.

The proof was six years of post-launch observation. I've seen what fails in real businesses. When a screen has too many states, staff hit the wrong button under pressure. When information requires scrolling, it gets missed. When error messages use product language instead of human language, staff stop trusting the product. The refresh was an opportunity to bake six years of learning into the system, instead of patching the existing UI tool by tool.

The trade-off was deliberate: glance-able means less information per screen. Some power-user features ended up gated behind a "more" tap. Power features used 5% of the time should not slow down the actions used 95% of the time.

Most “rewards” software is built for end customers. A retail business gives a customer a card and offers them discounts to come back. That market is saturated, and large players dominate. There's another problem nobody is solving: frontline workers in retail and hospitality are underpaid and undervalued, and the perks economy doesn't reach them. The corporate-perks platforms gate access behind enterprise pricing that small businesses can't afford.

Invert the audience. Teemie Rewards is a closed network. A small retail or hospitality business signs up and offers a perk to other Teemie businesses' staff. In return, their own staff get access to perks across the entire network. The card never goes to a retail customer. It stays inside the closed loop of frontline workers, verified through their existing Teemie staff status.

That closure is what makes the product distinctive — and it shaped every design decision:

1. Cards live in Apple Wallet and Google Wallet. No second app to install for redemption. Added once, just there when relevant.
2. Redemption is NFC tap at the merchant's POS — not QR code. Most small hospitality businesses already have NFC-capable POS hardware (Square, SumUp). QR codes add friction and feel low-trust at the counter. Tap-to-redeem feels ambient and modern.
3. Staff verification is automatic. Only verified Teemie staff get the card. That is the closed loop. No fraud surface, no signup workflow for redemption.
4. Positioning matters. The merchant landing page reads “your staff get perks at the network's businesses.” Not “loyalty.” Not “customer rewards.” A different conversation, a different design.

A closed network only works if the network grows. The launch playbook is a founding cohort — recruited city by city — who get value from giving and receiving simultaneously. Designing the landing page and the merchant onboarding flow was as much a design problem as the product itself. Four landing-page iterations later, the current version is the active base, with a Manhattan map section, two-logo nav, real product cards, and per-staff pricing presented clearly.

By the time the Rewards screens were shipping, the new design language was visibly better than the existing platform UI. The choice was: let the platform stay inconsistent (Rewards lives in 2026, everything else lives in 2019), or commit to refreshing every existing tool using the same language.

The hard part isn't the visual decision. It's the operational one. As a solo designer working across eight tools and a new product, with refreshes typically taking two to four screens per tool, the work fanned out to roughly forty screens in flight. Without a system, consistency breaks. Without a methodology, the work slows.

HTML-first as the design format. Every screen was built as production-fidelity HTML, with the design system extracted verbatim from the screens themselves — class names preserved one-to-one, no reinterpretation. Three benefits: I could render any screen in any browser at any moment to gut-check it; engineering would get a real prebuilt brief instead of a Figma reference; component reuse was enforced by file structure rather than goodwill.

As the work scaled, a mandatory pre-build protocol became necessary — rules I had to follow before writing a single line of HTML for any new screen. Always re-read the design system file (especially after a session break). Always check the canonical reference screen for the component type. Always stop and ask before inventing a new pattern. The protocol sounds like overhead. In practice it kept the system from drifting as more screens shipped.

By the end of the refresh: forty-plus shipped HTML mockups, a 125 KB design system file with twenty-five components across ten sections, a canonical reference screen designated for every component type, and a documented decision log capturing every material choice. The system isn't a starter kit. It's a record of what real shipped screens needed.