One Platform, Four Markets: Why We Didn't Build Four Apps

We built one platform and put four marketplaces on top of it. We did not build four separate apps. The hard problem in each of them is the same problem wearing a different name. A tutor's credibility, a personal trainer's credibility, a beauty professional's credibility, and a local advertising host's credibility all come down to the same question: can a stranger trust this person with money and access, before they have any first-hand experience of them? We solve that question once and reuse the answer, instead of solving it again for every vertical. That decision was made early, and we have kept it ever since. It is the argument this piece makes: verticalise the market, not the infrastructure.

The instinct we didn't follow

The obvious way to expand from one marketplace into several is to spin up a new codebase per vertical: a tutoring app, a personal training app, a beauty booking app, a local advertising app. Each one gets its own login, its own booking flow, and its own trust system, built by whichever team owns that vertical. That is the instinct behind most multi-vertical marketplace attempts. It fails for a boring, structural reason. The trust problem is almost identical across every one of those verticals, and only a small slice is genuinely different. Building four separate stacks means solving that shared problem four times over. Then you maintain four sets of bugs in code that all does the same thing.

Tutorwise runs on what we call the 80/20 platform model instead. Authentication, billing, profiles, bookings, the credibility scoring engine, communications, and referrals are shared infrastructure. We build that once and use it in every vertical: Tutorwise for tuition, Traderwise for trading education, Trainerwise for personal training, and Adspots for local advertising, with Beautywise next. Only a small remainder is vertical-specific code — the specific thing a subject-matter expert in that vertical actually does, and the specific way a booking works in that market. The line is deliberate, not incidental. Build, Operate, Govern sets out the operating model that makes maintaining that line possible at our scale. It is the same discipline applied here to product architecture, rather than internal process.

What actually differs between a tutor and a personal trainer

It is worth being specific about where that small vertical-specific slice really sits, because it is easy to assume trust looks completely different from market to market. It doesn't, much. What a parent needs to know before booking a GCSE chemistry tutor, and what a client needs to know before booking a personal trainer, are structurally the same question asked about a different subject: has this person actually done this before, with real people, and is there a real check behind their claims? The verification signals differ in detail. A tutor's DBS check matters in a way a personal trainer's doesn't. A personal trainer's qualification body matters in a way it doesn't for a tutor. But the shape of the answer is the same every time: verified credentials, a checkable history of sessions delivered, and feedback tied to real bookings rather than an open review box. How Tutorwise Scores Tutor Credibility: CaaS Explained describes that scoring model for one vertical. The same underlying engine, with different weighted signals, runs Trainerwise's verification and prices a personal trainer's credibility the same structural way, as shown in How Much Does a Personal Trainer Cost on Trainerwise?

Adspots is the sharpest test of the thesis. On the surface it looks like the odd one out: it is not selling a person's expertise at all, it is selling a physical or digital advertising surface by the hour. But the trust question underneath is identical. Does the buyer know, with evidence rather than a promise, that the ad they paid for will actually go up and actually be seen? That is exactly the same "verify, don't just claim" problem, applied to a surface instead of a person, and it runs on the same platform primitives. See How to Become an Adspots Host for what that verification looks like from the supply side, in a market with no tutors or trainers in it at all.

Why this is a bet on infrastructure, not on any one market

A single-vertical marketplace makes a bet that one market is big enough to justify building trust infrastructure from nothing. A platform strategy makes a different bet. It bets that a real trust system — the kind that survives scrutiny, not a five-star average anyone can fake — is worth building once, provided more than one market can use it. That changes the economics of trying a new vertical. Launching Adspots did not mean re-solving identity verification, payments, cancellation policy, or dispute handling. It meant asking what a local advertising surface needs on top of infrastructure that already existed, and building only that. The same will be true of Beautywise. A new vertical becomes a scoping exercise against existing infrastructure, not a from-scratch build. Work done once keeps paying out, instead of resetting to zero with every new thing we try.

This is also, honestly, a bet. Markets that look unrelated from the outside — tutoring, personal training, beauty, local advertising — are more alike underneath than most companies building single-purpose apps assume. We think that is true of most two-sided markets built on trust between strangers. We expect to keep testing that belief by adding verticals, rather than by declaring it settled.

The failure mode this avoids, and the one it doesn't

The failure mode a shared platform avoids is the one most multi-product companies eventually hit: four codebases quietly drifting apart, a bug fixed in one and not the other three, a trust signal that means something different depending on which app a user happens to be looking at. Shared infrastructure stops that drift. A fix to how verification works lands everywhere at once. A new signal added to the credibility model is available to every vertical, not just the one that happened to ask for it first.

It does not avoid the opposite failure mode, and we don't pretend it does. A platform that shares too much becomes generic, and a generic marketplace loses to a competitor who genuinely specialises in one thing. The discipline this requires is holding the line at 80/20, rather than letting it drift to 60/40 or 50/50. We share the trust and booking infrastructure. We keep subject-specific matching, exam-board specialisms, and a local advertising surface's proof-of-display genuinely specific to the vertical that needs them, built by people who understand that vertical rather than bolted on by a platform team that doesn't. Getting that boundary wrong, in either direction, is the real risk in this strategy — more than any single market underperforming.

Who decides where the line sits

A shared platform only stays disciplined if someone is actually responsible for the boundary between shared code and vertical-specific code. Otherwise every vertical team has an incentive to pull just one more thing into "shared" for convenience, or to fork just one more thing into "vertical-specific" to move faster this sprint. The line drifts either way, one small decision at a time, until nobody owns it. We handle that the same way we handle any cross-cutting decision at platform scale: through the Build, Operate, Govern model referenced above. A change that touches shared infrastructure — the credibility engine, the booking core, the trust signals every vertical depends on — goes through a different, higher bar of review than a change scoped to one vertical's own code. That is not bureaucracy for its own sake. It is the mechanism that keeps a fix in Tutorwise's booking flow from silently breaking Adspots' very different booking flow, because the two are properly separated rather than accidentally coupled.

The same governance question applies to trust itself. A credibility score only means something if the standard behind it holds, regardless of which vertical a user is looking at. A verified badge on a tutor's profile and a verified badge on an Adspots host's profile need to represent an equivalent amount of actual checking — not a stricter bar in one market and a rubber stamp in another. Letting that standard drift between verticals would be the fastest way to make the whole "verify, don't just claim" argument in this piece look hollow.

What we'd tell another team weighing the same choice

If you are deciding whether to build a second vertical as a separate product, or as an extension of an existing platform, ask the right question first. Don't ask "how big is the new market." Ask "how much of the trust problem in the new market is actually new." If the honest answer is "not much — it's the same verify-a-stranger problem with different evidence," building a second app is very likely wasted effort, duplicating work you have already paid for once. If the honest answer is "genuinely different — the buyer is trusting something structurally unlike anything the first platform verifies," that is a real signal to build separately, rather than force a fit. We have made that call four times now. Each time, the trust problem turned out to be the same problem in different clothes.

FAQ

Is Tutorwise the "main" product and the other verticals just extensions? Tutorwise came first. But the platform underneath — authentication, billing, the credibility scoring engine, bookings — was built to be vertical-agnostic from early on, not retrofitted after the fact. Traderwise, Trainerwise, and Adspots are full marketplaces on that same infrastructure. They are not add-ons to the tutoring product.

Does a shared credibility engine mean every vertical is scored the same way? No. The underlying engine is shared, but the signals it weighs are set per vertical. A DBS check matters to a tutor's score in a way it doesn't to a local advertising host's, for example. What's shared is the discipline of scoring from evidence rather than self-reported claims — not the specific formula.

Why add Beautywise rather than going deeper on the four existing verticals? Both happen in parallel. Depth on existing verticals and testing the platform thesis on a new one are not mutually exclusive, when the added cost of a new vertical is mostly scoping — not rebuilding trust infrastructure from zero.

What stops the platform becoming too generic to compete with a specialist? Holding the 80/20 line deliberately. We share trust and booking infrastructure. We keep subject- and market-specific matching, credentials, and proof-of-delivery genuinely specific to each vertical, rather than flattening them into a lowest-common-denominator design.

Could this model work outside marketplaces built on trust between strangers? The argument here is specific to trust-mediated two-sided markets, where the hard problem is proving credibility rather than, say, logistics or inventory. We would not claim it generalises beyond that, without testing it.