The Constraint Was the Moat

I have spent most of my working life building in regulated markets. Payments first, then money movement in its various forms, then crypto — which spent the better part of a decade insisting loudly that it was not a regulated market, right up until it discovered it had been one the entire time.

Across all of it, the most expensive mistake I watched founders make, over and over, in companies far better funded than mine, was the same one. They treated the rules as a tax on speed.

You know the posture. Compliance is a cost center. Legal is the department of no. The licence is a box to be checked as late as possible, ideally by someone else, ideally after the growth curve has made the company too important to stop. Move fast, and if you break something, you will by then have the money to fix it.

It took me longer than it should have to understand why that posture keeps losing. In a regulated market, the constraint is not a tax on the moat. The constraint is the moat.

Run the arithmetic from the other side

Here is the exercise I wish someone had walked me through at thirty.

Take the requirement you resent most. The one that adds eleven months and a small fortune before you can serve a single customer. Now stop asking what it costs you, and ask what it costs the next twenty people who want your market.

It costs them eleven months and a small fortune too — except they have to spend it after you already have customers, revenue, a reference list, and an operating history. Their eleven months are strictly worse than your eleven months were, because they are running them against an incumbent instead of against an empty field.

Ask the harder version: if this were easy, would your market still be available? Almost always the answer is no. A large, obvious, profitable opportunity that requires nothing but execution has already been executed. The reason there is room for you at all is usually the exact thing you are complaining about.

That reframe does not make the eleven months pleasant. It does change what you do with them.

Three things I would tell my younger self

Build the constraint into the architecture on day one. This is the one that actually costs money to get wrong, and it is where I have seen the most damage. Retrofitting auditability, data residency, consent, permissioning, or transaction monitoring into a system that was designed as though none of them existed is not a project. It is a rewrite, and it lands at the worst possible moment — usually mid-diligence, usually when the acquirer or the examiner is already in the room. Meanwhile the team that assumed the constraint from the first schema paid maybe fifteen percent more up front and never thinks about it again.

The general principle, and it long outlasts any particular regulation: constraints are cheap when they are assumptions and ruinous when they are corrections.

Hire the function before you need it. Everyone in a young company hires compliance late, for the entirely rational reason that the role produces nothing you can demo. Then it gets hired under a deadline someone else set, which is the most expensive way to hire anything — worse candidates, worse terms, no time to test judgment. And judgment is the entire job. A mediocre compliance hire gives you a list of prohibitions. A good one tells you which three of the twelve things you want to do are genuinely impossible and helps you build the other nine.

Never pitch the regulator as the enemy. This one surprises people who have not done it. Regulators are more available, more reasonable, and considerably more useful early than founders assume — particularly if you arrive before you have a problem, describe honestly what you intend to build, and ask what would concern them. The founders who did that got told, in advance and for free, which parts of their plan were unworkable. The founders who avoided the conversation found out the same thing later, in writing, with a deadline attached and their name on it.

The honest counterweight

I do not want to sell this cleanly, because the clean version has killed companies.

A moat only helps you if you survive the crossing. I have watched good teams with the right strategy die standing directly in front of the door — the analysis correct, the licence eventually granted, the runway gone eleven months earlier. Being right about a long game does not exempt you from the arithmetic of the short one. If the barrier takes eighteen months, you need to have financed twenty-four, and you need something to sell in the meantime that does not require the thing you are waiting for.

There is a second failure mode that looks like virtue. Some founders fall in love with the constraint and let it become the identity of the company. They build a beautiful compliance apparatus and forget that nobody has ever bought software because it was permitted. The constraint is a moat around a castle. It is not the castle. If there is nothing inside worth defending, you have built an extremely well-regulated way to lose money.

Why I still choose these markets

Given all that, why keep building in the hard ones? Partly temperament, I suspect. But there is a real argument too.

A market with no barriers is a market where the winner is decided by whoever can raise the most money and spend it the fastest. I have never been the person with the most money. In a market with a real barrier, capital still matters, but it stops being sufficient — you cannot buy your way past a requirement that takes calendar time, institutional trust, and a track record nobody can wire you.

Those are the only markets where patience is a competitive asset rather than a personality trait. That has always suited me. Most of the decisions I am proudest of over four decades have been decisions to accept a limit that made the product harder to build and the company slower to grow — including, more recently, deciding that a piece of software I own will never hold anyone else's money, which closed off an obvious business model and settled a whole category of question permanently.

The founder instinct is to ask how to get around the constraint. The better question, and the one that took me half a career to start asking first, is what the constraint is protecting — and whether you would rather be inside it than outside.