Nibbble

TL;DR

• Role: Founder, designer, product leader, and AI-powered engineer
• Timeframe: Jan 2026 to present
• Business problem: Independent restaurants need loyalty tools that fit how they actually operate. Most products are too thin for the owner or too heavy for the floor.
• What I changed: Designed and shipped a multi-tenant SaaS platform connecting owner administration, staff workflows, and customer engagement under one system.
• Proof: Production v1 launched 2026-04-22 at app.nibbble.io with Square POS and Stripe billing, three role-specific portals, a shared design-token layer, validated through a four-restaurant customer council with two in active beta.

The problem was not loyalty points

The easy version is a punch card with a login screen. Independent restaurants need a system that respects how they actually operate: the owner thinks about margin and repeat visits, staff need speed between orders, customers need a reason to return without homework.

Started with the operating model, not the feature list. Nibbble is three products sharing one spine (owner, staff, customer), each with a different job on the same architecture. The harder challenge was keeping that system coherent while building primarily with AI agents. Without the right scaffolding, agents drift the system every week.

Three portals, one product

3 points

123

1Customer: scan and go2Staff: one action in the rush3Admin: carries the weight

01 · Customer: scan and go

Check points, redeem rewards, view history. The smallest scope, tuned for a few seconds at the counter.

What I did

• Defined the product strategy for independent restaurants, not enterprise chains. The customer council of four restaurants validated decisions before they shipped.
• Designed the core experience across owner, staff, and customer workflows. Three distinct surfaces with different primary actions: admin carries full configuration weight, staff is built around one high-frequency action during rush, customer is built for scan-and-go on a phone.
• Built production v1 with Square POS integration, Stripe billing, multi-tenant Postgres with row-level security, and scheduled operational jobs. Launched 2026-04-22 at app.nibbble.io.
• Created a shared design-token system so three portals feel like one product. Three distinct layouts, one coherent system.
• Established an AI-assisted development model with governance rituals: peer review by a second AI model, documentation-sync gates, codebase memory so agents understand the system before editing, and hard safety rails in the runner (not the prompt). Speed did not become drift.

What changed

Nibbble moved from idea to live SaaS with a business model, a customer council, a production foundation, and a system for keeping product decisions coherent as it grows.

• Production multi-tenant SaaS running at app.nibbble.io since 2026-04-22: three portals, Square POS, Stripe billing, multi-tenant data layer.
• Customer council of four restaurants, two in active beta. Operator-validated decisions are the asset at this stage, not revenue.
• A documented multi-agent development stack where design, product, and engineering choices stayed connected through the build.

The executive signal: turning ambiguity into a shipped product without letting it fragment.

Reflection

The product is early. The next proof should be usage, retention, revenue, or operator behavior, not more build velocity. Running this with a Director of Product Design team, I would put a research lead on standing customer council synthesis and a design systems lead on the three-portal token layer earlier, so the maintenance cost of three surfaces stays low as the team grows.