The button I didn't build: phronesis for deciding what gets shipped

A neighbourhood barbershop, open for nearly four decades. By the book, the site I had to rebuild was begging for online booking: calendar, slots, email confirmation. I had it half designed before the first meeting.

Then I asked how people actually book. The answer was: they call, and the younger ones send a WhatsApp. The phone sits on the counter. Sometimes you walk in and wait, and that wait is part of the place.

I didn’t build the calendar. It was the best technical decision of the project, and it shows up in exactly zero lines of code.

Techne is not phronesis

Aristotle separated two kinds of knowing that we tend to treat as one. Techne is the craftsman’s knowledge: how a thing is made well. Phronesis — practical wisdom — is something else: knowing what should be done in this particular situation, which no general rule can settle for you.

The distinction isn’t academic. The techne of a booking engine is learnable: availability, collisions, time zones, reminders, cancellations. Anyone with a bit of craft picks it up. Phronesis is answering whether that barbershop needs a booking engine at all, and the handbook can’t answer it, because the handbook talks about “service websites” and this isn’t a service website: it’s a shop with a man, a phone, and customers who have been walking in unannounced for thirty years.

Aristotle said deliberation is never about what is eternal, but about what is in our power and could be otherwise. The trade has good rules. Good rules describe the aggregate. No client is the aggregate.

The general rule is true and doesn’t apply here

“Every service website needs online booking” is a reasonable statement. In most businesses of that kind it cuts friction and captures demand after hours.

And it would still have been a mistake in that shop. Not because the rule is false, but because a general rule gets applied to particular cases and the particular case has the last word. Bad judgment isn’t a matter of holding bad rules; it’s applying them without looking at who is in front of you.

What you install when you apply the rule blindly isn’t a feature. It’s a promise. A public calendar promises that the slots it shows are real, that someone keeps them current, that if you book Thursday at 5pm there will be a chair on Thursday at 5pm. That promise rests on one person whose hands are busy all day.

The tool that gets in the way

Heidegger described the difference between the tool that is ready-to-hand and the object that is merely present-at-hand. A working hammer disappears: you drive the nail, you don’t think about the hammer. Only when it breaks does it show up as a thing — and then it’s in the way.

A booking panel nobody opens is precisely that: a broken tool that has turned into an object. It takes up space on the owner’s mental counter, produces a small pang of guilt every time he remembers he hasn’t checked it, and eventually lies to whoever books. The phone, meanwhile, was already invisible — it had been transparent to everyone for decades.

Replacing an invisible tool that works with a visible one that has to be learned is a bad trade, even when the second one is technically superior.

What I did build

Nothing spectacular. A WhatsApp button that opens the chat with the message already started. A call button that calls. Opening hours visible without scrolling, and an address linked to the map. Static page, instant load, no admin panel because there’s nothing to administer.

Dull to describe, and hard to defend in a meeting where someone else is showing an animated calendar. But it’s what people in that neighbourhood already knew how to use, and what the owner can sustain without changing how he works.

Phronesis cuts both ways

This isn’t a defence of minimalism. Practical wisdom doesn’t say “build less”. It says “look at the case”.

Same year, another project: a mobile vehicle appraisal service. There I did build slot booking with payment up front, which is a good deal more involved than a barbershop calendar. And it was right, because the business already worked that way — closing visits and taking payment over the phone, painfully — so online booking didn’t ask for a new habit, it removed work. When a system formalises something that already happens, adoption takes care of itself. When it tries to create a habit, ask who is going to pay for the learning.

Same architectural decision, opposite outcome. Not because one has better technical judgment behind it, but because they’re different places.

The four questions I ask now

• Who maintains this on a Tuesday afternoon? If the answer is “nobody has time”, the feature is already broken — it just doesn’t show yet.
• Does it replace a habit or compete with one? What replaces gets adopted. What competes with the phone, the WhatsApp, or walking in and waiting, loses.
• What happens if nobody opens it? If the answer is “the client lets someone down”, that’s not an optional feature. It’s a liability with a nice interface.
• Does the boring alternative already work? Almost always yes. And almost always I dismiss it out of professional habit rather than judgment.

The craft of deciding

In Ockham’s razor I wrote that every abstraction is a bet on the future. So is every feature — but it bets on something harder to predict than code: on a person, their hands, their schedule, their habits.

A developer with techne knows how to build anything. That’s necessary, and it isn’t the hard part. The hard part, the one that gets paid for and doesn’t automate, is looking at one concrete business and deciding what — out of everything you know how to build — should not be built here.

Aristotle thought phronesis can’t be taught by rules: you acquire it by deliberating on real cases, and by getting it wrong. A few projects in, I can confirm it. The only rule that has held up is to ask before designing, and to sit with the discomfort of shipping something smaller than what I knew how to make.