PufferPOS

The owner did not always have a clear view of the day. Cashiers and baristas depended too much on memory. Inventory was painful. Closing a shift was messy. A cancelled order could become a mystery by the end of the week.

Even when software existed, it often felt disconnected from how people work under pressure.

So I kept rebuilding the idea. Not as a startup at first. More like an obsession with a workflow I had seen up close.

That eventually became PufferPOS.

A checkout screen alone would not fix the operation.

The product had to connect what happens at the counter to what the owner sees later. Completing one order can affect stock, table state, customer history, shift totals, and daily reporting.

I built the MVP end to end around that loop:

POS and active order flows

table and floor management

products, recipes, ingredients, and stock

shifts, expenses, vendors, and customers

dashboard reporting and daily snapshots

staff roles and resource permissions

organization-scoped data and billing gates

onboarding with realistic demo data

a public read-only menu

The feature list is wide. The point is the connection between the features.

PufferPOS is live at pufferpos.com .

A new user can create a workspace, seed it with demo data, explore the operation, and start configuring a real café without me standing beside them. The live product includes the cashier loop, tables, stock and recipes, expenses, customers, staff permissions, dashboard reporting, billing gates, and a public read-only digital menu.

PufferPOS is now a real product people can enter, configure, and use. That changes the work: every decision has to survive a busy shift, a new staff member, an owner checking the numbers later, and the ordinary edge cases that appear after launch.

The POS screen received the most iteration. I watched how cashiers moved through the old versions, then kept removing friction. The current screen is sparse because speed, predictability, and low cognitive load matter more than showing everything at once.

I made onboarding part of the product. Empty operational software feels dead, so a seeded workspace gives people something real to touch before their own menu is ready.

I also kept the public menu read-only. Online ordering, delivery, memberships, and events are useful directions, especially for workspaces. They were not more important than making the core staff workflow dependable.

That was a lesson I had to learn more than once: a bigger vision is easy. Choosing what deserves to exist now is the harder product skill.

I chose Next.js, TypeScript, Firebase Auth, Firestore, Firebase Storage, Firebase Admin, NextAuth, and Vercel cron routes.

Firebase was a speed decision. The product relies heavily on live order, stock, table, and dashboard updates. Firestore gave me that without building WebSockets, Redis, pub/sub, and a heavier backend before the product needed them.

The tradeoff is real. More advanced querying, search, cost control, and reconciliation may eventually justify a different data layer. That migration would be expensive, so I would only make it when usage proves the need.

The dashboard taught me the clearest version of this tradeoff. The first version fetched every order in a date range and calculated insights from the raw data. It stayed close to the source, but large ranges meant more reads and repeated work.

I moved reporting to daily snapshot documents updated by order events. The dashboard now reads one document per day, with a reconciliation job available to rebuild snapshots from real sales data. Fewer reads, faster reporting, and one more place where correctness has to be designed rather than assumed.

For a POS, trust is the real technical product. Totals, stock, receipts, permissions, refunds, and offline recovery have to become boring.

Puffy is live inside PufferPOS as an operations assistant that helps an owner understand what is happening in the workspace and guides a menu-import workflow. The interface is designed around conversation, visible progress, and reviewable work so the operator can stay in control of the catalog.

The menu-import flow is intentionally recovery-aware. It shows what has been read, keeps useful completed sections, and gives the operator a way to review or continue when a provider response, image, or normalization step needs attention. The goal is simple: AI should shorten the work without hiding the decisions that still belong to the operator.

Launch visual for Puffy, the PufferPOS operations assistant.

Campaign concept framing the one-person café operator problem that PufferPOS is designed to reduce.

Digital-menu campaign visual showing a smoother café browsing experience on mobile.

Lifestyle campaign concept about giving operators more time.

Brand campaign visual positioning PufferPOS for independent cafés, restaurants, and workspaces.

Poster concept translating slow order handling into a clear PufferPOS promise.

Campaign concept for an operational update: more control over the day, with PufferPOS as the product context.

These launch visuals are part of the PufferPOS brand I shaped alongside the product. They make the promise legible before someone opens a dashboard: fewer jobs competing for the owner's attention, clearer decisions during a shift, and more room to run the business.

The next stage is deeper adoption with independent cafés: make the daily workflow dependable, tighten the order, stock, permission, receipt, tax, refund, and offline edges, and keep improving the product around how cafés actually work.

Puffy is the next product surface I am developing: practical answers from the workspace data, with the context and source visible enough for an owner to decide what to do. The work ahead is to make reconciliation easier, keep operators in control of consequential changes, and earn trust one useful workflow at a time.

PufferPOS brings together the work I like owning: product decisions, interface design, engineering, and taking the product to market.