Build the hard side of a marketplace first, by hand

Every marketplace has an easy side and a hard side. The easy side arrives if the product is any good. The hard side has to be acquired one participant at a time, usually by phone, usually by someone who finds that work unpleasant.

Getting this the wrong way round is the standard way to spend a year building something nobody can use.

Which side is hard#

The hard side is whichever one has less to gain from a market existing.

For skip hire, that is supply. A householder needing a skip has an immediate problem and will happily use whatever answers it. A skip operator with three vehicles and a full order book this week has no problem at all, and a listing on a new directory is a speculative cost against a benefit they cannot yet see. Buyers show up because they need something. Suppliers show up because someone convinced them.

The test is simple enough to apply before you build anything. For each side, ask what happens to them if your marketplace does not exist. If the answer is roughly nothing, that is the hard side, and it is where the entire risk of the business sits.

What we did instead#

We built SkipHireCompare properly. Service areas as real geometries in PostGIS so that “who covers this address” is a spatial query rather than a postcode string match, which matters because skip hire radii are irregular and overlap and the marginal customer is always at the edge of one. A map interface that distinguishes paid placement from standard listings so the commercial model is visible to the buyer. Direct debit collection through GoCardless with a card path retained, because recurring low-value business billing in the UK works better on direct debit.

All of that is in production and all of it was worth building eventually. The problem is the word eventually. It was built before anyone had established that a skip operator would pay for a position, and that is the one fact the business depends on.

The site is live now and the supply is thin, which is a worse product than no site at all, because a comparison tool with gaps teaches the buyer that the answer is not here and they do not come back to check.

The version we should have built#

One region. A spreadsheet. Twenty operators called individually and asked directly whether they would pay for enquiries, and at what price.

If enough of them say yes, you have the number that justifies the platform, and you build it with real suppliers waiting rather than an empty database. If they say no, you have learned it in a fortnight for the cost of a fortnight.

The reason this is uncomfortable is that it involves selling something that does not exist, to people who are not expecting a call, before you have anything to show. Building the platform first is more pleasant. It also lets you defer the only question that matters, which is why it is so appealing.

The general form#

This is the same error as building a filing product because the regulation was compulsory, which we also did. Both are cases of doing the legible work first and the decisive work later.

The rule we now try to hold to: find the single fact the business depends on, and get evidence for it using the cheapest method available, even when that method is manual, unscalable and slightly embarrassing. Software is how you scale something that already works. It is a poor instrument for finding out whether it works.

There is a version of this that goes too far, and it is worth naming. Some things genuinely cannot be tested by hand, and the geospatial matching here is close to that line. You cannot fake “who serves this postcode” across a region with a spreadsheet for long. The distinction is that we needed that capability to serve customers, not to find out whether suppliers would pay. Build what the test requires. Leave the rest until the test passes.