This lunch is 500 yen ($4.80) at Sukiya, a Japanese fast food restaurant which belongs to a category with about three big competitors.

I love the aesthetics of this category and they’re under remarked upon.

I think people underestimate QSRs in terms of social utility, but Sukiya et al describe themselves as mission-oriented enterprises. I believe this is largely sincere, and goes back to the 60s and 70s, when the clientele was primarily manual laborers who had migrated to work.

Japan was not a rich nation at the time, and day laborers in particular were both unlikely to be able to cook for themselves and unlikely to have much of a food budget, and so the chains sprung up offering an honest-to-goodness cooked meal delivered in under a minute for cheap.

This heritage continued over the years, even after Japan became a much more wealthy nation, and these chains function as social support and dignity for folks in diminished circumstances.

They also are a wee bit of a cartel, and I appreciate the aesthetics of the cartel:

Back when I was first in Japan, in the mid 2000s, there was an increase in the price of beef.

And the heads of the three chains got together, and decided that the price of the basic beef bowl needed to increase, but given the economic circumstances how could they hold the line.

One of the big promises of software is composability. You can build rich, powerful experiences out of basic building blocks.

APIs add new things to the toolbox. For example: Treasury, which lets an app/platform store, move, and track a business’

I've been a small business owner and can talk at length about SMB banking, and will later, but let's put on the software developer hat right now.

Lots of software talks about money, keeps records about money, does calculations about money, but can't *touch* money.

This is extremely frustrating when you're building SaaS apps for businesses, because you have total control over your UX right until your app needs to touch money... at which point all data about it lives in a silo you can't access.

So you generally push work to the operator.

For example, suppose you’re writing a business-in-a-box system for electricians, including an invoicing feature.

You need to be able to read bank transactions to reconcile. You probably can't. The owner can. So you ask the owner to do mind-numbing work a computer does better.

It sure would be great if your business customers had bank accounts you could actually introspect and operate on their behalves! You could just get the list of incoming payments and match against the invoices.

There is some software to write but it is not rocket science.