Case StudyI couldn't find a system that fit my café. So I built one.
What started as an internal POS/KDS evolved into a multi-tenant hospitality operating system — built through an AI-native development workflow and tested every day inside the business it was designed for.
The system I wanted didn't exist
I was preparing to open my own coffee shop, Origen 22. I looked at the POS and hospitality systems available to me, but none matched exactly how I wanted the business to operate.
Instead of adapting the café to the software, I decided to build the software around the café.
OrigenOS started as a relatively small internal tool to control the essentials:
The initial goal was never to build a huge SaaS. It was to solve my own problem. As new operational needs appeared, the system grew with them.
First functional version in 6 days
OrigenOS wasn't built in six days — the first functional version was. The repository's first six consecutive days contain 173 commits. By day six, working software existed:
That version worked. It was also nowhere near the product OrigenOS would eventually become.
From POS to operating system
The scope didn't grow because of a roadmap. It grew because running the café kept surfacing the next real need.
Building the product from inside the business
OrigenOS is developed inside the same business that uses it. Most features don't start in a backlog — they start behind the counter.
Counter vs. table service
Counter
- Order
- Pay
- Prepare
- Deliver
Table service
- Open table
- Send items
- Prepare
- Add more items
- Close table
- Pay
One order, multiple stations
A single order can include a cappuccino and a plate. The bar prepares one, the kitchen prepares the other — so the system routes each item only to the station that has to prepare it, in real time. The bar display also runs on tighter timing than the kitchen, because drinks should come out faster than plates.
Kitchen KDS
Toast
Bar KDS
Cappuccino
The combo engine
Take a real offer: coffee of choice + 2 medialunas. For the customer it's one simple product. For the system it means representing fixed items and customer choices inside a single commercial entity — which then flows into pricing, order representation and station routing.
COMBO
├── 2 × Medialunas — fixed
└── Coffee — customer choice
├── Espresso
├── Cappuccino
├── Latte
└── …
Simple customer experiences often require non-trivial product models underneath.
AI didn't define the product. It changed how fast I could build it.
Every feature follows the same path — from a real need observed in the café to validated software in production. AI accelerates the middle of that path, not the ends.
Real need
Every feature starts with a problem or need I observe in the operation.
Product definition
I define what should happen and how it should behave.
Discussion
I use Claude conversationally to explore implementation options, edge cases, interactions with existing features and potential problems.
Specification
That conversation becomes a concrete specification.
Implementation
Claude Code accelerates the implementation.
Testing
I test the behavior and verify it matches the original need.
Production
When it's ready, the team uses the change inside Origen 22.
Iteration
Real feedback comes back into the product.
Human-owned. AI-accelerated.
Human-owned
- Product direction
- Operational knowledge
- Prioritization
- UX decisions
- Business rules
- Validation
AI-accelerated
- Implementation
- Research
- Refactoring
- Debugging
- Testing assistance
- Repetitive engineering work
This split is conceptual, not absolute. The message is simple: AI accelerates implementation. Product judgment remains human.
Built in software. Tested in hospitality.
OrigenOS isn't software I built for a hypothetical user. I am the user. My team is the user. And every day the café opens, the product gets tested in production.
One application, readable in twenty seconds
The entire system — POS, kitchen displays, admin, background jobs and public API — runs as a single Next.js application. High level, it looks like this:
Problems worth solving
Five problems that shaped the engineering — each one driven by an operational constraint, not a technology choice.
Multi-tenant isolation
Every query and every row must stay inside its tenant. Isolation is enforced in two independent layers — application and database — so a single mistake can't leak data.
Real-time station synchronization
An order placed at the POS has to appear on the right kitchen or bar display instantly, and stay in sync as its state changes.
Order state management
Orders move through states that don't always advance linearly — adding an item to a ready order intentionally reopens it. Closing an order coordinates payment, fiscal receipt, stock and loyalty in one transaction.
Fiscal & external integrations
Electronic invoicing depends on external providers. When a provider is down, the POS keeps selling — receipts queue offline and drain automatically when connectivity returns.
Reliable background printing
The server never talks to a printer directly. Print jobs are queued and a small agent inside the café's network picks them up — designed so the same ticket can't print twice.
For engineers who want the details
Optional reading. The story above works without this section — this is for the technical reader who wants to go one level down.
Frontend
- Next.js 16 App Router, React 19, strict TypeScript
- Tailwind CSS 4 with Radix UI primitives
- Kitchen displays driven by realtime subscriptions, not polling
- Installable PWA for counter devices
Backend
- Single application — no separate backend service
- Server Actions for human-triggered mutations
- API routes for crons, webhooks, the print agent and a versioned public API
- Separate auth contexts for staff, customers and platform admin
Data
- PostgreSQL on Supabase
- Row-level security plus an application-level tenant guard on every query
- Per-location pricing, stock and fiscal configuration
- Realtime channels for station displays
Security & reliability
- Fiscal credentials encrypted at rest
- Signed webhooks and rate limiting on public endpoints
- Offline queues for fiscal receipts and printing
- Backwards-compatible migrations — the multi-tenant evolution never required a rewrite
One café first. More later.
Today OrigenOS runs one business: Origen 22.
For roughly another month, the plan is to keep using it intensively inside the café — dogfooding: using your own product every day before asking anyone else to.
The goals of that phase:
After that: start onboarding other food-service businesses. The architecture is already multi-tenant — but there's a difference between an architecture that supports many businesses and a product proven by them. I'd rather earn the second before selling the first.
I like building software this way.
Real problems. Fast iteration. Production feedback. If that's how you want products built, let's talk.