The Barber Game

There was no brief

Two friends and I started The Barber Game with an idea and nothing else: there should be a better way for people to find and connect with barbers. No specification, no product, no agreed definition of the problem worth solving first.

My job was to decide what we should build and why. That meant product discovery, research, experience strategy and design — working directly with my co-founders, with customers, and with our engineers.

The problem we assumed wasn't the problem

We started where most people start: scheduling. Open slots, bookings, calendars. So I went and talked with independent barbers, shop owners and clients about how the work actually happens.

Two things came back that changed the product.

First, scheduling is a solved problem that nobody is emotionally invested in. Before anyone books a barber, they have to decide whether they trust that barber — and that decision is where all the friction lives.

Second, and more usefully: there is no reliable way to know what a barber can actually do. Star ratings average an entire person into a single number. They tell you nothing about whether this barber can cut coily hair, work a straight razor, handle a wheelchair-height chair, or work respectfully at a hospital bedside.

So we stopped building a booking tool and started building a matching system: pair a specific customer need to a specific, verified barber capability.

Three tiers of capability

The core architectural decision was to stop treating "skill" as one thing. A capability on the platform exists in one of three states, and the difference between them is the entire product.

Ratings attach to the capability rather than the person. A barber can be exceptional at one thing and untested at another, and the system says so plainly instead of averaging it away.

Closing the loop

A verification system is only as good as its weakest input. If verification can be self-asserted, bought, or farmed, the whole structure collapses back into the star ratings we were trying to replace.

So we built it around something that cannot be faked at a distance: both people, physically present, confirming the work at the moment it was finished. That one constraint shaped everything downstream.

1. A barber asserts a capability.
2. A customer with that specific need is matched to them.
3. The appointment happens in person.
4. Both people confirm it took place, in the room.
5. The rating attaches to that capability, not to the barber as a whole.
6. Proven capability raises standing — which produces better matches, which produces more proven work.

We call the loop the Trust Engine. Everything else in the product is either feeding it or spending what it produces.

Where the demand actually is

Once capability was the unit of the system rather than availability, a market opening became visible that we had not been looking for.

Nearly every product in this category is built for the same transaction: a walk-in customer, a shop chair, a standard cut. But a great deal of real barbering happens somewhere else entirely — often not in a shop at all — in settings where the need is highly specific, the stakes are higher, and there is currently no reliable way to find a qualified person.

Those segments are underserved precisely because a star rating cannot describe them. Proven capability can. The architecture we built for trust turned out to be the thing that opens a market nobody else is positioned to address.

Mapping that market — which segments, in what order, and why — is the part I'd rather walk through in person than publish.

What "the game" actually means

The name gets misread as gamification — points, streaks, leaderboards. It means the opposite.

Barbers already have careers. They are craftspeople, business owners, counselors and mentors, and many of them will know a client as a child, a teenager, an adult, and eventually as a parent bringing in their own kids. What they don't have is any structure that recognizes that career or carries any of the benefits an employer would provide.

So proving a capability doesn't unlock a badge. It unlocks a ladder — a progression that begins with a professional identity you can actually demonstrate, and climbs toward the kind of stability independent work has never carried with it. We modelled the structure on how guilds have done exactly this for other professions built on independent operators.

Designing while building

I work directly with engineering as concepts move from Figma into the product. One co-founder is our backend engineer; a front-end engineer handles implementation and wiring. Research, design and build inform each other continuously, and the roadmap changes when what we learn says it should.

The sharpest lesson of the last year is a management one. Generating screens has never been cheaper — and a pile of screens is not a working product. Most of my effort now goes into sequencing: deciding what has to exist first, what can wait, and how long the real engineering will actually take. The constraint stopped being imagination a long time ago.

What this was an exercise in

Nobody handed us a problem definition, a spec, or a design system. The work was deciding what the thing should be, building the argument for it, getting three founders and an engineering team aligned behind it, and then taking it all the way into production.

The Barber Game started as an idea for finding barbers. It became a system for deciding whom to trust — and a case for what verified work should be worth to the person who did it.