Wink Pings

Boba Shop Statechart: Take the Money First, Then Check the Boba

Kevin Ngo used JavaScript and @poteto's /statechart skill to diagram a boba shop as a statechart. Open source, generated with Claude Opus 5.5. Four diagrams cover ordering, the business day, preparation, and the boba pot; the most painfully real detail is hidden in the refund branch.

Kevin Ngo posted four boba-shop business diagrams in a tweet. They're drawn in JavaScript, based on @poteto's /statechart skill, open source, and made with Claude Opus 5.5.

A statechart is a diagram from software engineering that describes state changes: what state an object is in, what event triggers it to move to the next state, and which states can run in parallel. A boba shop is a clever choice of subject—readers don't need a technical background to immediately check whether the diagram is right.

The first diagram is called "the business of boba·I An order from the line to your hand." The flow starts with queuing, then ordering, payment, preparation, calling the number, and pickup. There's one branch in the diagram: if the boba runs out, refund.

Ordering flow statechart, from queuing to pickup, including a refund branch after payment

A commenter pointed out that the refund check only happens after payment. Take the money first, then discover the boba is gone. That order stands out clearly in the diagram. Another commenter said the boba-running-out branch proves someone has actually stood in that line.

The second diagram is called "the business of boba · II A day at the shop, 7 am to 9 pm." Prep at 7 a.m., open, quiet, people come in, get busy, school lets out, peak, close at 9 p.m.

Boba shop business-day statechart, from 7 a.m. prep to 9 p.m. closing

One commenter said the peak path skipping the four-hour rule is the most realistic bug in the whole shop. The diagram doesn't explain the four-hour rule, but that comment points out a real-world compromise.

The third diagram splits the employee and the boba pot into two parallel states. The employee switches between idle and making drinks: when an order comes in, unless they're cooking boba, they make the drink, shake and seal it, call the number, and return to idle. The boba pot goes from full to low; when the employee is idle, they start a new batch, and once the boba gets soft, it is discarded.

Statechart of the employee and boba pot as two parallel states

This diagram carries the most information. It separates "person" and "pot," each with its own states, while they also trigger each other. Running low on boba isn't an exception; it's a routine branch. Restocking has to wait until the employee is idle, and that constraint is clear in the diagram.

The fourth diagram has no caption and is placed at the end for easy comparison.

The fourth supplementary diagram from the tweet

One commenter summed it up in a reply: when using the statechart skill to draw a boba-shop business diagram, ask all the state questions up front before you start—less rework; don't start writing until the requirements are aligned. That comment sounds more like hard-won experience than the diagrams themselves.

Another commenter asked whether there were any unexpected states, such as an order stuck between paid and in preparation. That question is worth keeping. The value of a statechart often isn't in what gets drawn, but in the branches you're forced to answer while drawing it.

Original tweet: https://x.com/kevin_t_ngo/status/2116270190040416313

发布时间: 2026-10-31 22:37