Nibbble

TL;DR

One-line outcome. I founded Nibbble, designed every surface, wrote 387 of the 412 commits on main, and put web v1 in production at app.nibbble.io.

Role and scope. Founder, principal designer, product leader, and the engineer at the keyboard with AI. Kicked off 2026-01-26, launched 2026-04-22. Team: me plus a PM and a mid-level engineer; earlier contributors Ahsan Amjed, zedain01, zpal01. Customer council of four restaurants, two in active beta as of 2026-05-10.

Three metric chips.

• 387 of 412 commits on main authored by me as of 2026-05-10.
• Web v1 in production since 2026-04-22 across three portals (admin, staff, customer), Square POS, Stripe billing, multi-tenant Postgres with RLS.
• 17 auto-fix commits landed via a local Ollama triage-and-patch loop.

Context

Independent restaurant operators do not want enterprise loyalty software. They want a tool that disappears at the counter and shows up in the back office only when something needs attention. The category is crowded with point systems that bolt onto a POS, charge per transaction, and treat the line staffer as an afterthought. Three audiences with very different jobs share one product: an owner configuring rules and reading revenue, a line staffer checking a guest in during a Friday rush, and a customer scanning a phone with one hand while paying with the other.

The real problem was not how to build a loyalty product. It was how a small team building primarily with AI agents could ship three role-specific surfaces under one design language without the agents drifting the system every week.

Mandate

Build a multi-tenant restaurant loyalty SaaS into production, with a customer council pressure-testing decisions before they ship. Use the build as the proving ground for AI-native product design at Director of Product Design level. Every load-bearing choice (component library, agent contracts, portal architecture) has to defend itself as a design decision.

Scope

I own product vision, brand, IA, data model, three portal designs, agent operations, vendor selections, the customer council, and the merge button on every PR. I also built the design system, HeroUI v3 component contracts, repo and vault AI contracts, the local triage loop, the docs-sync gate, and the cross-AI review CI rule. Authority: total. Founder and owner.

Key decisions

HeroUI v3 over shadcn/ui, MUI, and Chakra. When most of your code is written by AI agents, the component library is the biggest contact surface between the agents and the brand. I picked HeroUI v3 because it was the only major React library at selection time that shipped four AI-native artifacts as part of the library itself, not as documentation: agents.md, llms.txt and llms-full.txt, a live MCP server, and agent skills. Pick wrong and every AI-authored PR needs cleanup. Pick right and the agents stay inside the system. Trade-off: early v3.0.x coverage gaps, paid down by keeping components.json for shadcn-style scaffolding on the long tail.

Three portals over one role-switched app. The cheap path was role-based UI gating in a single Next.js app. I shipped three distinct surfaces instead. Staff is built around one high-frequency action (check-in during rush). Customer is built around scan-and-go on a phone, one hand on the device and the other on a card reader. Admin is the only place that carries full configuration weight. Cost: more components to maintain and three layouts to keep coherent. Paid down by a shared token layer and the HeroUI v3 system.

Two local models split by job, not one cloud model for everything. Vitest failures during AI-assisted development were getting chased by hand, which is exactly the work AI is good at. A small local model runs four-class triage (source_bug, test_bug, flaky, unknown). A stronger local coder model runs the patches, scoped to an allow-listed path. Cloud Claude stays on the human-in-the-loop side. The loop is right on the easy ones, bails safely on the rest, and never burns cloud credits unattended. (Model slugs: see /ai-fluency.)

Hard safety rails in the runner, not the prompt. Allow-list (lib/**/*.ts, app/api/**/route.ts), deny-list (tests, env files, __mocks__), one file per attempt, three retries max, every fix as its own atomic commit, gated by OLLAMA_AUTOFIX=1 so a normal npm test cannot trigger it. Reversibility over cleanliness. A runaway agent on production code is one rebase from disaster. This design makes a bad fix one git revert away.

Customer council as a standing practice, not interview cycles. Four restaurants form a continuous council, two active in the loop. Decisions get pressure-tested against real operators before they ship. At zero paying customers, the operator-validated decisions are the asset, not a vanity revenue line.

What changed

Product. Before: a vault-stage spec and a Figma file. After: a production multi-tenant SaaS at app.nibbble.io running three portals, Square POS webhook ingestion, Stripe billing across Starter, Growth, and Scale tiers, multi-tenant Postgres with row-level security, and live crons (expire-points daily, retry-webhooks every 15 minutes, refresh-square-tokens daily, NIB #16 spend-window sweeper).

Org. Before: a one-person idea. After: a small team plus a documented multi-agent stack with cross-AI peer review as a CI rule, not a hope.

System. Before: nothing. After: an operating model with the repo and a parallel Obsidian command center, each AI tool reading its own rulebook against one source of truth. A codebase memory graph (ADR-0021), a post-commit hook keeping the graph fresh, and a pre-push gate blocking code changes that ship without matching docs updates.

Measurable outcomes

• Web v1 in production at app.nibbble.io since 2026-04-22, stable.
• 387 of 412 commits on main authored by Mohsin (94 percent) as of 2026-05-10.
• 17 auto-fix commits landed via the local Ollama loop, real diffs not demoware.
• Three portals (admin, staff, customer) on one shared token layer.
• Customer council of four restaurants, two in active beta as of 2026-05-10.
• Zero paying customers as of 2026-05-10. Stated, not hidden: operator-validated decisions are the asset at this stage.

Leadership lens

Tool and library selection is design leadership. Choosing HeroUI v3 was a multi-year call about how AI agents and humans collaborate on UI, made on what the library was built for, not on what was familiar. The same pattern repeats in the model split, the safety rails, and the customer council: pick the artifact whose interface fits the work, design the environment the AI operates inside, keep humans on the merge button.

What I did with my hands

Player-coach proof. I author the code, not just the spec.

• 387 of 412 commits on `main` as the AI-enabled engineer. git shortlog -sne --all is the receipt: 359 from mohsin.amjed@gmail.com and 28 from mohsin@mamjed.com. Remaining commits: Ahsan Amjed, zedain01, zpal01, dependabot.
• Local triage and auto-fix loop. I wrote scripts/triage.mjs, scripts/auto-fix.mjs, and scripts/autofix-watch.mjs. The deterministic prompts, allow-list, and deny-list live in code, not in a config the agent can rewrite.
• Repo and vault contracts. CLAUDE.md, AGENTS.md in the code repo; CLAUDE.md, AGENTS.md, GEMINI.md in the Obsidian command center. Each AI tool reads its own rulebook against one source of truth.
• NIB #14 AI onboarding spec. I authored the spec, migrations, and PR #91.

AI threading

The interesting work is not "use Claude to write code." It is the scaffolding around the agents.

Stack. Claude Code for primary development. Codex CLI for independent code review. Gemini CLI for research. OpenClaw for routing. Local Ollama for triage and patches. Full model slugs and routing logic: see /ai-fluency.

Component library as agent contract. The repo's CLAUDE.md carries an explicit HeroUI v3 docs index header so any new Claude Code session knows where to look before generating UI. The result: agent-authored UI matches the system without per-PR cleanup.

Codebase memory graph. codebase-memory-mcp adopted 2026-04-27 as ADR-0021. CLAUDE.md mandates graph queries before grep. A post-commit hook keeps the graph fresh.

Cross-AI peer review. A CI gate enforces @codex review on all PRs. Claude-authored PRs get reviewed by Codex by rule, not by goodwill.

Docs-sync pre-push gate. A pre-push hook blocks code changes that ship without matching docs updates. Agents cannot let code and documentation drift apart.

Local auto-fix loop with hard rails. Allow-list: library code and API routes only. Deny-list: tests, env files, mocks. One file per attempt, three retries max, every fix as its own atomic commit, env-flag gated so a normal test run cannot trigger it. 17 commits landed, each with a short post-mortem in the repo.

Where human judgment stayed. I hold the merge button. Agents propose, I decide. I own the IA for the three portals, the architecture decisions, the launch-gate call on 2026-04-22, vendor selections (Supabase, Cloudflare, Square, Stripe), and the HeroUI v3 and codebase-memory-mcp decisions.

Reflection

AI productivity comes from designing the environment the AI works inside, starting with the artifacts whose interfaces were built for that work. The library choice, the vault constitution, the codebase memory layer, the triage loop, the docs-sync gate, the cross-AI review rule: each is a design decision, not a dev-ops afterthought.

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.