Field note
The coffee credit wasn't the hard part.
What a small hospitality program taught us about operational software.
A resident gets a free coffee.
That sounds like a coupon.
It isn't.
While building around Frenchies Coffee Bar, the interesting part wasn't the interface. It was everything that had to be true before someone could walk into a location, receive what they were promised, and leave without anyone having to explain the system.
- Who qualifies?
- What are they entitled to?
- How does the person behind the counter know the benefit is valid?
- Has it already been used?
- What happens if the customer wants something more expensive?
- Who needs a record afterward?
None of those questions are really about coffee.
They're about coordination.
01We thought we were building a benefit
The visible experience was deliberately simple.
- A person has an entitlement.
- They visit a participating business.
- The benefit is recognized.
- They redeem it.
- The transaction is recorded.
The customer shouldn't need to understand anything behind that.
But making the frontstage simple pushes complexity backstage.
Someone has to determine eligibility. The customer needs a way to establish that eligibility without friction. The merchant needs enough information to fulfill the benefit without becoming an administrator. And someone eventually needs to understand what happened and what it cost.
A simple benefit starts becoming a small operating system.
See the build → Frenchies Coffee Bar · Built 00102The merchant can't become the system
This was one of the more useful lessons.
The local business shouldn't have to carry the operational complexity of the program.
Imagine the alternative. The person behind the counter has to remember:
- which people qualify,
- which program they belong to,
- what they're entitled to,
- whether they've already used it,
- what happens if they want an upgrade,
- and what needs to be recorded afterward.
At that point, we haven't solved the software problem. We've moved it onto a human being.
That's backwards.
The system should carry the rules. The person should deliver the coffee.
High tech backstage. High human frontstage.
03The edge case revealed the architecture
The interesting part of operational software often appears in the exception.
Consider a simple one: a resident is entitled to a drip coffee. They want a latte.
If the system only understands “free drink,” this becomes awkward. But that's not actually what the customer has. They have an entitlement with value.
The included value can be applied. The customer can pay the difference. The system can record what happened.
A small exception suddenly exposes the architecture underneath the experience.
Who qualifies?
What are they supposed to receive?
What actually happened?
What did the program produce and cost?
That framework wasn't created because it sounded good on a website. The operational questions demanded it.
04The handoff is the product problem
The coffee crosses organizational boundaries. One party establishes the benefit. Another person receives it. A local business fulfills it.
Software has to preserve the rules as responsibility moves between them.
The visible experience can still feel extremely simple. But underneath it, information has to survive every handoff without changing meaning.
That became the more interesting problem. Not: how do we make someone redeem a coffee? But: how do we make a promise portable across multiple people, organizations and systems without requiring each of them to reconstruct the rules?
That's infrastructure.
05Small programs expose big systems
Frenchies did not prove that the world needs better coffee software. That isn't the conclusion.
What it showed us was how quickly a seemingly simple experience becomes a coordination problem when multiple parties become responsible for keeping the same promise.
A small program can involve a property, a customer, a merchant, software, money, rules, exceptions, and reporting.
The promise can still fit in one sentence. The operating system underneath it cannot.
That's why small implementations can be useful. The handoffs are easier to see. And once we started seeing them here, we started noticing the pattern elsewhere.
06The coffee wasn't the product
The most valuable part wasn't the coffee. It wasn't even the redemption screen. It was the infrastructure required to let a simple promise cross organizational boundaries without degrading.
The customer shouldn't need to understand that infrastructure. The merchant shouldn't need to become that infrastructure. And management shouldn't have to reconstruct what happened afterward.
That's the lesson we carried forward.
Great once can run on attention. Great repeatedly needs a system.
This became one of the operating patterns behind our broader Promise Gap thesis.