Skip to content
Alex Crowley
Alex Crowley

Mar 2026 – now · Co-founder

OpenStable

A UK marketplace for horse owners, the yards that stable their horses, and the professionals who care for them. I set its strategy and build it.

Role
Strategy, design and build
Built
With Claude Code · 2,000+ commits
Platforms
Web, iOS and Android
Users
About 1,000 a month ·

01

Three sides

Horse owners need a stable. Yards have empty ones. Farriers, physios and grooms need clients nearby.

Many UK horse owners keep their horse at a livery yard: a stables business that rents out a stable, grazing and care by the month. Finding one often means asking around in Facebook groups.

OpenStable puts all three groups in one place. Owners search yards by what’s free right now. Yards and professionals get found, and every enquiry is tracked for both sides.

Each side gets its own home in the same app, so a horse owner, a yard owner and a farrier each open a different OpenStable.

Search: 5 yards within 15 miles of GU1, each with a photo, its livery types and how many spaces are free.
A horse owner searching for yards near Guildford, in the iOS app. Staging data with fictional yards.

02

The plan that didn’t work

Before launch I expected yard owners to pay for their listing. Six months in, they hadn’t.

The easy reading was that the price was wrong. When I went through the data, the problem was simpler than that, and more embarrassing.

We had already built the paid features, for yards and for professionals, and given them away free. Almost nobody used them, because we’d told almost nobody they existed. Our own pricing page told yard owners they didn’t have a feature they did.

So the first fix wasn’t a price. It was pointing people at what was already there: when a stable sits empty, tell the yard owner who nearby is looking for one.

A yard owner’s home for Meadowbrook Livery: 8 horse owners nearby are looking for a yard, enquiries awaiting a reply, and the listing as riders see it.
A yard owner’s home leads with who nearby is looking. Staging data.

03

What I changed

Charge for the direction demand flows, not for who someone is.

Being found, being messaged and replying stay free for everyone. What you pay for is reaching out to people who didn’t ask for you.

A farrier with a full round never needs to go looking, so never pays. A new physio building a client list does. It’s one price list, and nobody is charged for their profession.

I also ruled out commission. Livery runs to thousands of pounds a year, and a fee on it only teaches both sides to settle up off the platform.

And I put livery first. Our own count of what people ask for showed far more demand for stables than for sharing or loaning a horse.

Who needs you: 9 horse owners looking within 40 miles, each with the livery they want, when they’re moving and an Invite to enquire button.
“Who needs you”: owners looking near a yard, each one an invitation away. Reaching out is the paid side. Fictional owners on staging.

04

How I build it

I build all of it with Claude Code: the website, both phone apps and the server behind them.

Web, iOS and Android share one codebase and one set of design tokens, so a screen is designed once for every platform.

Building alone with an agent means the process has to catch what a team would. Every bug fixed goes into a log the agent reads before it writes code, so the same kind of mistake doesn’t come back.

My co-founder runs acquisition: bringing yards, owners and professionals on board. The product and the calls on this page are the side I own.

A farrier’s home: 2 people nearby want their services, 5 active clients, and their listing as clients see it.
A farrier’s home in the same app: clients, pending work and who nearby wants them. Staging data.

05

Calls I made

The ones that shaped the product, in order.

  1. A third side: professionals.

    Owners don’t only need a stable. They need a farrier and a physio near it. Professionals got their own profiles, search and messages.

    Ruled out: a yards-only directory

  2. Native apps, one codebase.

    I moved the product into one repository with Expo, so the website and both apps share their screens’ design and data.

    Ruled out: three separate builds

  3. A log of mistakes, read first.

    Each fix adds the kind of bug and how to spot it. Claude reads the log before it writes code.

    Ruled out: fixing the same bug twice

  4. Reprice while it costs nothing.

    With a handful of paying customers, a higher price risks almost no churn. With hundreds, it would. So I raised it then.

    Ruled out: waiting for more data

  5. A local gate, not paid CI.

    Every change runs the full test suite on my machine, and the results go into the pull request before it merges.

    Ruled out: paying for CI before revenue

06

Where it doesn’t hold

It’s early, and some of this is still a bet.

  • The pricing is reasoned, not proven.It comes from how people behave on OpenStable. Revenue is still small, so it hasn’t been tested at scale.
  • I don’t run acquisition.My co-founder does. The user numbers are both of ours; the product calls are mine.
  • It’s UK only, and livery comes first.Sharing and loaning horses are there, but they get less of my time, on purpose.
  • A solo build has a single point of failure.The tests and the mistakes log make it safer. They don’t replace a second engineer.