Every founder building in healthcare, legal, financial advice or childcare arrives at the same conversation, and it arrives framed as a legal question. Do we need HIPAA. Do we need to be a covered entity. What insurance do we carry. Who signs what. That framing is what the whole information environment around regulated categories offers you, so it is the natural place to start.
Those questions matter and they are not the hard part. The hard part is that in a regulated category, verifying your supply side is not a compliance checkbox sitting off to the side of the product. It is the onboarding flow. It is the listing flow. It is the reason a provider signs up on Tuesday and cannot take a booking until the following week, and it is where most of your supply-side drop-off happens.
I have got this wrong on our own work, more than once, by treating verification as a phase two problem. You build the marketplace, you get the booking loop working, and then you go to bolt on credentialing and find that the thing you bolted on has added more than a week to your supply activation time. A week is the difference between a provider who lists and a provider who forgets they signed up.
This article is about designing that layer first, and what it does to the rest of the build.
Why The Regulated Version Is A Different Product
A general services marketplace and a regulated services marketplace look identical in a wireframe. Search, profile, book, pay, review. The difference is what has to be true before a listing is allowed to exist.
On a general marketplace, a provider can list in five minutes. They enter their details, they publish, and the market decides whether they are any good. Reviews do the quality work over time. Your trust layer is mostly reputational and mostly retroactive.
In a regulated category that model is not available to you. A physiotherapist who is not registered cannot be allowed to appear in search results at all, and no amount of reviews fixes that after the fact. The verification has to happen before the listing goes live, which means it sits directly in the path of your supply growth. Every extra day of verification is a day the listing is not earning.
That single constraint cascades into most of the product decisions that follow.
The Four Things You Are Actually Verifying
It helps to separate these, because they have different failure modes and different refresh cycles.
Identity. This person is who they say they are. Standard identity verification, and the easiest of the four, because there are good providers and the check completes in seconds.
Credential. This person holds the qualification they claim. A degree, a certification, a registration number.
Licence and standing. This person is currently permitted to practise, in the jurisdiction where the booking will happen. This one behaves differently from the others, because it is not a fact, it is a state. A licence is valid until it is not.
Insurance and indemnity. This person carries cover appropriate to the work, and that cover is in force today.
Only the first of those is a one-time check. The other three expire, and they expire on their own schedule rather than yours. That is the whole design problem in one sentence.
What Expiry Does To Your Booking Flow
Here is the scenario that decides whether your architecture holds. A provider’s licence lapses on the fifteenth. They have four bookings on the calendar for the twentieth.
You need an answer for that before you launch, because the flow will produce it whether you designed it or not. The options are:
Block at listing. The listing comes out of search the moment the licence expires. Existing bookings stand. This protects new demand and leaves you carrying four bookings against an unlicensed provider, which is exactly the exposure you were trying to avoid.
Block at booking. The listing stays visible but cannot be booked. Slightly softer, same exposure on the existing four.
Cancel forward. Existing bookings are cancelled and the buyers are told why, or told something less specific. This is the only option that closes the exposure and it is also the one that damages buyer trust and provider relationships.
Grace window. A defined period where the provider can renew without losing their listings or their bookings, after which the harder rules apply.
There is no free answer here. Most of the regulated marketplaces that work well use a grace window with escalating restriction, and they start warning the provider a long way out. The point is that this is a product decision with a real trade-off, and it belongs in the spec rather than in a support conversation on the twentieth.
“In a regulated marketplace your verification layer is not a legal requirement sitting next to the product. It is the first thing your supply side experiences, and it sets how fast your marketplace can grow.”Darren Cody, Marketplace Studio
Verification Time Is A Liquidity Metric
This is the reframe that changes how the build gets sequenced.
Time from provider signup to first bookable listing is a liquidity metric, and in a regulated category it is usually the constrained one. Not demand. Not conversion. The clock that runs while a credential is being checked.
Worth instrumenting from day one, split into the parts you control and the parts you do not:
- Signup to documents submitted. Yours. This is a form design problem and it is fixable.
- Documents submitted to check initiated. Yours, if you have automated it. Someone else’s if a human has to open an email.
- Check initiated to check returned. Usually not yours. Registry response times, third-party verification services, human review queues.
- Check returned to listing live. Yours.
Splitting it matters because the instinct is to attack the whole number, and three of those four segments respond to different work. Shortening the registry response time is not available to you. Shortening the two ends is entirely available to you, and on most builds those two ends are where the majority of the elapsed time sits, because a provider abandons a document upload form and nobody notices for three days.
Where The Compliance Obligation Actually Sits
Two practical points, and then a caveat.
The first is that your regulatory position depends on your role in the transaction, and that role is a product decision, not a legal one. A marketplace that lets a patient discover and book a practitioner, and passes no clinical information, is in a materially different position from one that hosts intake forms, consultation notes or messaging about symptoms. The second is handling protected health information. The first is mostly not. A message box is the most obvious thing in the world to add and its regulatory weight is invisible in a wireframe, which is why it tends to get built before anyone has priced what it pulls into scope.
The second point is that the obligation usually attaches to the data, not to the category. It is not that healthcare is regulated and therefore everything you touch is regulated. It is that specific categories of data carry specific handling requirements, and a marketplace can often be designed so that the sensitive data flows between the two sides without transiting your systems in a way that pulls you into scope. Whether that is the right design depends on what your product is for, and sometimes the answer is that you need the data and you accept the obligation. But it is a choice, and it is cheapest to make it before the schema exists.
Do Not Build The Verification Service
One more thing, because it is where a lot of budget goes to die.
The temptation in a regulated category is to build the credentialing infrastructure, because it feels like the defensible part. It is not, and it is enormous. Primary source verification against dozens of registries, each with a different interface and a different refresh cadence, is somebody else’s whole company. There are companies that do only this, and they are worth what they charge.
What is defensible is everything you wrap around it. The onboarding flow that gets a provider through document submission without dropping out. The state machine that knows a credential is thirty days from expiry and does something useful about it. The listing logic that fails safe. The buyer-facing display that shows a verification status in a way that actually builds confidence rather than raising a question the buyer had not thought to ask.
Buy the check. Build the flow around it.
Where This Leaves You
If you are building in a regulated category, the sequence that tends to hold is: decide what you are verifying and how often, decide what happens on expiry, instrument the activation clock, buy the verification rather than building it, and only then design the search and booking experience on top.
That order feels backwards, because search and booking are the parts you can picture and the parts you can show an investor. But the verification layer determines how fast supply can come on, and in a regulated marketplace supply is almost always the side that gates everything else.
We have built platforms in categories where a listing cannot go live until a credential clears, and the pattern is consistent enough that we now treat the activation clock as the first metric on the board rather than the fifth. Our regulated marketplace page covers how the category differs more broadly, and pre-development is where the verification layer gets specified. If you are working through this and want to talk it out, that is a good conversation to have early rather than after the schema is set.
