Building Empire

An industry of relationships. The barber industry runs on relationships that no single product holds. Every side of it has a need, and every need has its workaround.

The bet was that they connect. Each of those needs could carry a product on its own. The bet behind Empire was that they are worth far more connected: the barber a client books through the app is the barber a shop wants to hire.

Nothing tied to an address. The other half of the bet was that none of it should be. Barbers move between chairs, shops, and cities, and their clients travel too. In a directory built around shops, a barber who leaves starts over — new profile, no reviews, no clients. Empire is built around the barber, so all of it goes where they go.

The read came from inside the industry. It did not come from a deck. Our growth and marketing lead founded, ran, and sold two barbershops in Buenos Aires before moving to Barcelona to open more. He had staffed a chair, chased a no-show, and hired off a recommendation. Knowing which problems were real, and which only sounded real, is why several of the decisions below cut features rather than adding them. I pressure-tested his read with barbers in Barcelona, Buenos Aires, and Miami and heard the same workarounds — a signal that this problem was not local to one scene.

How a three-sided marketplace fails. It fails in a specific way: you build everything for everyone, ship late, and none of the sides has enough of the others to be useful. The hardest work on Empire was deciding what the first version would not do.

Four questions had to be answered before any screen could be designed:

• Who is this for, and where do they meet? Clients, barbers, and businesses have genuinely different jobs. Forcing them into one app would have meant an onboarding that asked everyone to declare themselves and a navigation carrying three unrelated mental models.
• What earns money, and what has to stay free? A network is worthless when it is empty, so charging to look would starve it. The actions that create real value — like publishing a barber profile for client discoverability and accepting booking requests — are what a barber will pay for.
• How much of the transaction do we own? Payments and dispute handling are enormous to build and heavier to maintain. Barbers already get paid in the chair.
• Why would anyone trust it? Inviting a stranger into your home, or hiring one into your shop, is a trust problem before it is a UX problem.

Product decisions before screens. I answered those four questions as product decisions first, then designed to them.

1. Two apps, not one. Splitting consumer from professional let each app open on the need its user came for — a list of nearby barbers, or a dashboard of today's requests — instead of a role-selection screen. Barbers and businesses share the Biz app because they are the two halves of the same professional loop: one is looking for work, the other is looking for talent.

The biggest cut: hiring waits. Both talent loops were mapped end to end and then left out of v1. A hiring marketplace needs businesses and barbers already on the platform to be worth opening, and building it first would have delayed the one loop that can start from a single barber and a single client. Bookings ship now, clientele accrues, and hiring arrives when there is a network for it to work on.

2. Free to browse, paid to participate. Anyone can explore the network and build a profile as a draft. Empire Pro unlocks the actions that create business value — publishing a profile, accepting bookings, posting events and listings — and the hiring actions are gated the same way once they arrive. Messaging is what makes value stick: the longer a barber works through Empire, the more of their bookings and client conversations live in one place, and the more the subscription is worth keeping. Value is visible before the paywall; the paywall sits exactly where money starts moving.

3. Own the booking and the conversation, not the payment. The apps collect precisely enough to make the handoff — service, time, address, contact — and in-app messaging keeps the follow-up attached to the booking instead of scattered across texts. Payments are where we stopped. This was the clearest case of industry experience beating instinct: barbers already get paid in the chair, so a payments and dispute-handling stack would have delayed launch by months to replace something nobody was asking us to replace.

4. Trust through reviews and verification. Clients review barbers. Barbers review clients, visible only to other barbers — a professional back-channel about who is worth the trip. Verified badges mark confirmed accounts on both sides.

Mapping before designing. I worked the whole system out as maps first — every role, branch, gated action, and notification — so that scope arguments happened on a diagram rather than halfway through a build. The maps are unglamorous, and they are the reason the two apps stayed coherent.

The flow that had to be right. A booking is the one moment both apps have to agree on, so it is worth following all the way through — a client picking a barber, and the barber answering. It is also the clearest test of the two-app decision: the same event, shaped completely differently for each side.

Two halves of one booking. The client's half stays close to how people already choose a barber — filter by whether the barber travels to you, look at the work, then pick a service and a time. The barber's half is a decision screen: the job, the client, and their standing in one place, then three real answers rather than yes or no. Propose a new time exists because the honest answer is usually “not then, but I can do Thursday,” and losing that to a decline loses the booking.

Growing the network from the barber’s side. A marketplace with no clients is worth nothing to a barber, and a marketplace with no barbers is worth nothing to a client. Rather than spend our way out of that, we gave every barber a referral code of their own. They hand it to clients they already have; the client books through Empire Client and gets 10% off any service; and the code only works for the barber it belongs to.

The referral loop does three jobs at once. The client arrives with a discount and a reason to book in the app instead of over text. The barber brings an existing book onto the platform rather than waiting for one to accumulate. When the request lands, the barber sees exactly whose code produced it — which is a more convincing argument for Empire Pro than any marketing copy we could write.

A system built to be built from. The brand had to read urban and creative without tipping into either corporate blue or streetwear pastiche. I set a black-and-white base with a single confident blue, paired a condensed display face for screen titles with a highly readable UI face for everything else, and documented the tokens, components, and modal patterns the developers work from directly. Every screen above is built from it.

Where it stands. Both apps are on TestFlight now, in a closed beta with barbers in Barcelona, and a public launch is the next step. Nothing has shipped publicly yet, so there are no adoption numbers to report — what exists is a defined product where there was an idea, a build that matches the design, and the first feedback coming back from the people it was built for.

What I would carry forward. The decisions that mattered most were subtractive. Not building payments, and holding the entire hiring marketplace back from v1, are the reasons two apps reached barbers’ hands at all. Holding a scope boundary is hard when every cut feels like giving up ambition. I learned to argue about the shape of the product instead of the length of its feature list.

What is next. Both apps went out on TestFlight in August 2026, and the barbers testing them are setting the polish list that stands between the beta and a public launch — the last thing between Empire and the App Store. The questions I most want answered: whether a barber’s own code is enough to move their existing clients into the app, whether the professional side returns for events and listings between jobs, and whether the paywall lands where value is felt rather than where it merely blocks.