A 0 → 1 operations app, built around one question.

I was brought in to design a few merchant-facing dashboard cards. Each one looked like a small visual task, and each one raised a product question I could not answer from the design file: what does this number actually mean, what time range is it counting, what does an empty card mean. So I wrote the first PRD, the product spec, to settle those questions, and the work grew from a UI task into owning the product.

Every card pulled the same way. The surface question was about pixels. The real question underneath was about whether a merchant could trust the number enough to act on it.

The cards that started it, shipped: each one is a definition made visible — a metric, its period, its freshness.

Research was not a phase. From launch through every iteration we ran partner interviews, merchant feedback rounds, and workshops, and the inputs kept feeding decisions. The surface requests were fragmented: tips by employee, fee breakdowns, transaction search, refunds from the phone, batch close, which is the end-of-day settlement that sends a day’s sales to the bank. The root was always the same, though: the feeling that money is out of control.

A market signal sealed it. Generic growth-analytics features showed under 1-in-10 paid retention in the field. We considered leaning into accounting and rejected it: bookkeeping already has dedicated tools, and we are a payments company. Our unfair advantage is the transaction data flowing through our own payment stack. So the product moved off the generic pitch and onto the merchant’s own words.

The app was already live on iOS and Android with early partners, and the early signal was good. Adoption roughly tripled over two months inside that early-partner group.

Then I was asked to push downloads and adoption. Testing said the product was not ready to scale: unclear refresh states, inconsistent time logic, numbers merchants could not explain. In payments, scaling a product people do not yet trust does not just burn users. It burns the partners who put their name behind it. I recommended pausing the growth push and fixing the foundation first. The CEO aligned on a foundation sprint.

Decision

Pause the growth push. Fix the foundation before scaling adoption.

Why

Testing showed merchants could not yet explain the numbers, and data people do not trust will not survive scale.

Trade-off

Slower short-term growth, in exchange for long-term partner trust.

Result

The CEO aligned on a foundation sprint.

A time filter is not a UI control. It is a promise about what the number means.

Case A · the 23:59 decision

A same-day custom range could come back empty or misleading, because the end time defaulted to 00:00. The system was treating a date as a single instant. The merchant meant a full business day. So I worked the boundary problem all the way through, and rejected every clever answer before settling on the plain one.

It is not technically perfect. A day does not really end at 23:59. But it is the clearest boundary a merchant and a support agent can both point to, so that is the one we shipped.

Case B · time semantics, locked

Day, Week, Month, and Year stopped being loose labels and became product definitions: each runs from the start of the period at 00:00 to the latest synced time. Now product, engineering, sales, and support all explain the same number the same way.

Case C · range versus freshness

I split two questions that used to share one label. They are different trust questions, so they never collapse into a single number. And when a sync fails, the app keeps the last good data with its freshness label, instead of dropping the merchant onto a blank screen.

I also defined event tracking, so future prioritization could weigh partner anecdotes against what merchants actually do in the app.

With the data trustworthy, the next move was not “add AI features.” We restructured the app around two scenario families pulled from real merchant workflows, and most of what changed is not AI at all. The scenarios define the workflow. AI fills only the gaps where it genuinely helps.

Both scenarios start from the same place: the merchant is away from the counter, with only a phone.

status · working prototype, not shipped

Scenario 1 · Watch, anomalies surface themselves

A terminal goes offline and every card payment starts to decline. That pattern should flag itself right away, not wait to be found at close-out. The same goes for a single odd transaction: a missing tip, or a tip far below normal. Catch it early, cap the loss.

Scenario 2 · Act, find one transaction and fix it

A customer calls asking for a refund. The merchant is not at the store and will not open a computer. They search the way they remember it, in plain language, pick from the matches, review the drafted refund, and confirm.

Guardrails

Companion case, same employer, different surface: the partner platform, where partners onboard and manage every merchant.