Perfectionist about the foundation, fast about everything else

You can’t train a customer

Nanda isn’t running a warmindo. He’s building a product to sell into them, and that makes easy to learn much harder than it sounds.

Build an internal tool and you can train people — it’s your staff, it’s their job, a day of onboarding is affordable. Sell into thousands of independent warung and you can train nobody. Nobody runs a session for a shop with four employees, two of whom are family. The software teaches itself on the first shift, or it gets abandoned and the next shop hears about it.

So learnability wasn’t a quality of the product. It was the product. And it isn’t a thing you can evaluate in Figma — you can’t tell whether something is easy to learn by looking at a picture of it. You have to give it to someone and watch.

Where the perfectionism went

The baseline document was the slow part, and I was deliberate about it to the point of being annoying. Tokens, spacing scale, every interaction state, what a component does when it’s empty, loading, offline or wrong.

Everything after that was fast, and the reason is leverage. Anything built on the foundation inherits whatever’s in it, so a spacing scale that’s wrong isn’t one bad screen, it’s forty. A screen built on a settled foundation doesn’t need deliberation — it needs to exist, so somebody can react to it.

Requirements first, then competitive research, then structure with ChatGPT — flows, screen inventory, what each screen owes the person using it, still no pictures. Then straight into Claude Code. Every iteration after that happened on the running thing.

A mockup shows what something looks like. It can’t show what happens when the connection drops halfway through a sale, or whether eight taps feels like eight. In a till, those are the decisions.

Can I name the problem that put this here?

Software like this fails in a specific way: it gets designed to look impressive in a screenshot rather than to be operated for ten hours. So every element has to pass one test. If the honest answer is it makes the screen more interesting, it comes out.

That test does most of the visual work. Containers are earned — a border means “this behaves as a unit”, not “these pixels are related”, so grouping is done with alignment and dividers, which don’t stack into a cage. One large number and one dominant action — the amount due is the only 34px thing in the product because it gets read aloud across a counter, and Bayar is the only filled red. Five type sizes in total; a sixth would mean the hierarchy isn’t doing its job.

And nothing inside a card is absolutely positioned, because absolute placement holds at exactly one width and the density control changes that width.

Cashier takes money, owner checks money

Seven screens. Kasir is where the shift happens. Laporan is the owner’s, and arguably the more important of the two — Nanda’s buyer isn’t the cashier, it’s the person who wants the day’s takings without doing sums. Those two are the business case; the rest are the operational remainder.

A few decisions that came from the domain rather than from preference. Offline is the normal case, not an error — the sale continues, cash still works, and QRIS and card say why they can’t and what to do instead. Stock is what the cook thinks is left, so running out mid-order shows a notice at completion rather than blocking the sale; the food is already being made. Tax is off by default, because most warmindo sit below the PKP threshold and charge no PPN. And Rupiah has no practical subunit, so nothing renders a decimal anywhere.

Switches instead of options

I built a sandbox around the prototype: a panel of switches for every decision Nanda and I had disagreed about. Photo size. Tax on or off. Grid or table. Three, four or five columns. Order panel left or right. Online or offline. Stock normal, low, or sold out. Phone, tablet or desktop.

He could flip any of them himself, mid-conversation, on the real screen. That changed what a review is. Instead of me presenting two options and him imagining the difference, he clicked between them and had an opinion in about four seconds. The configuration encodes into the URL, so the version we agreed on is a link rather than a description.

It’s still live — open it and flip the switches yourself. Both options below are real states of the prototype, not mockups of what was rejected.

He wanted big photos

It’s food, the photos are the appeal, and on a single screen in isolation he was right — they look better. What the running prototype showed is what they cost.

And he wanted the phone to do more

Closer to feature parity with the desktop layout — the order visible at all times rather than behind a bar. A reasonable ask, and it survived right up until it was running on an actual phone.

This is the one I’d point at hardest, because a mockup would have argued the other way. A phone screen on a Figma canvas, viewed at 100% on a 27-inch monitor, looks roomy. In a hand, behind a counter, with a queue, it isn’t. No amount of looking at that file would have told him. Ten seconds of holding it did.

Both of those arguments are why the sandbox has a photo-size switch and a device frame. The switches aren’t hypothetical options — they’re the things we disagreed about, made flippable.

What I’d do differently

I’d use Figma again, and I now know exactly how far. Figma is better for deciding what something looks like — layout, hierarchy, the feel of a screen. Five versions there takes minutes and takes considerably longer in code, and working entirely in code cost me exploration.

What I’d stop doing is building the deep system in Figma. Variant matrices, component libraries, token definitions. A Figma variant matrix is a description of a system. The code is the system. Maintaining both means maintaining a thing that lies.

The second one is less flattering. I audited the build against its own documents late rather than early, and found six places where they’d drifted apart — including the baseline document itself, which had the wrong brand hex and an outdated type scale. Two screens disagreed about which product sold best. That is the exact failure this method exists to prevent, and it happened anyway, because nothing was checking.

So: Figma for the look, code for the system, the source of truth is whatever runs — and something has to verify that the documents still describe it. Next time that check is a step, not a memory.