Marketplace AB5 Compliance: Build It Right or Lose

The Legal Decision That Came Before the Booking Flow

A while back I co-founded a premium local-services marketplace in California. The idea was simple on the surface: connect families with independent providers in high-touch family services, the kind of work where someone enters your home and works with people you care about.

Before I wrote a single line of the booking flow, I had to answer one question that could blow up the entire company. Are the providers contractors or employees?

In California, you don't always get to decide that for yourself. Marketplace AB5 compliance can answer it for you, and usually not in the direction a founder wants. Get the answer wrong and you're not running a marketplace. You're running an unlicensed staffing agency with a six-figure tax bill compounding in the background.

Here's the thing most founders miss: legal structure is as load-bearing as any line of code. It is not a "figure it out later" problem. Treat it that way and you're pouring a foundation on a fault line, then acting surprised when the cracks show up after you've raised money and hired a team.

I've built 15+ AI systems across regulated and unregulated businesses, and the pattern is identical every time. The structure decides what you're allowed to build. The product sits on top of it.

So I made the legal calls first. Marketplace model, not employer. Providers carrying their own insurance. Revenue from fees, not wages. Each one shaped the code that came after.

In this article I'll walk through what AB5 actually does to a services marketplace, the three structural decisions that survive it, and what doing it wrong costs you. This is the stuff I wish more founders pressure-tested before they fell in love with their booking flow.

What AB5 Actually Does to a Services Marketplace

The ABC test in plain English

AB5 flips the burden of proof. Under California law, a worker is presumed to be your employee unless you can prove all three prongs of what's called the ABC test.

The ABC Test - three prongs a worker must clear to be a contractor

• Prong A: The worker is free from your control and direction in how they do the work.
• Prong B: The work is outside the usual course of your business.
• Prong C: The worker is independently established in that trade or business.

You have to clear all three. Miss one and the worker is an employee, full stop.

Prong B is the one that quietly kills most marketplaces. If your business is the service, then your providers are doing your core work, by definition. A house-cleaning company whose product is clean houses can't easily argue the cleaners are doing something outside its usual course of business. They are the business.

That's the trap an independent contractor marketplace in California walks into without realizing it.

Why marketplaces are the obvious target

Marketplaces look like the perfect AB5 target because the economics depend on not paying employer costs. Regulators know this. So do plaintiffs' attorneys.

Reclassify your providers as employees and the bill arrives all at once: back payroll taxes, workers' comp premiums, overtime, unemployment insurance, plus penalties stacked on top. Then come the class-action lawsuits from providers who say they were misclassified.

This is not theoretical. The big gig platforms have been sued and fined into the hundreds of millions over exactly this question. They had armies of lawyers and they still bled.

A pre-launch startup does not survive that. The math isn't "we'll fight it later." The math is "we never launch a model that invites it." That's why ab5 worker classification has to be answered before the product exists, not after a complaint lands.

The Marketplace Model: Why We Aren't the Employer

Connecting, not employing

The first structural decision was the foundation: position the company as a true two-sided marketplace. A venue that connects families with independent providers. Not a company that delivers the service itself.

This isn't marketing language. It's the honest answer to prongs B and C. If the marketplace is a connection layer, then the actual service work happens outside the company's usual course of business, and the providers are running their own operations.

The two-sided marketplace legal structure only works if it's real all the way down.

Providers run their own businesses

That meant building the operations so providers genuinely behave like independent businesses:

• They set their own rates within published ranges.
• They choose which bookings to accept or decline.
• They build and own their client relationships.
• They operate under their own business identity, not ours.

Here's the honest limit, and I want to be blunt about it: you cannot fake this. If you control schedules, set fixed wages, train providers on your method, and direct how the work gets done, no clever terms-of-service paragraph saves you. A court reads the actual relationship, not the PDF you made everyone sign.

The structure has to live in the operations, not just the contract.

This is the same lesson I keep running into everywhere. The wedge that makes a business defensible is almost always the boring plumbing, not the AI. The structure does the work. The marketing is just describing it after the fact.

In a services marketplace model, the plumbing is the legal architecture. Build that wrong and the prettiest booking flow in the world is decorating a liability.

Insurance and Liability: Providers Carry Their Own

The second structural decision: every provider joins the marketplace carrying their own liability insurance. We required $1M per occurrence and $3M aggregate, verified at onboarding.

This does two jobs at once.

First, it reinforces that providers are independently established businesses. A real business carries its own insurance. Someone who genuinely operates as their own enterprise has a policy in their own name. That directly supports prong C of the ABC test. It's evidence, not just paperwork.

Second, it protects the marketplace from being the deep pocket when something goes wrong. And in a high-touch, high-stakes service, something eventually goes wrong.

Think about the exposure honestly. When you're connecting a family with someone who enters their home and works closely with vulnerable people, the liability surface is enormous. An injury, an accident, an allegation. If the marketplace is the one carrying that risk, one bad incident can end the company.

By requiring providers to carry their own coverage, the risk sits with the party actually performing the work. The marketplace verifies the policy at onboarding rather than self-insuring the providers' work, which is exactly what an employer would end up doing.

I also flagged a future path on the roadmap: insurance billing as a revenue and trust layer down the line. Offering providers a way to source coverage through the platform, building it into the product as a deliberate feature rather than bolting it on after a crisis.

That distinction matters. Deciding it as a roadmap item means you design the data model and the onboarding flow to support it from the start. Bolting it on later means a painful migration and a half-broken experience. I'd rather plan the door than knock a hole in the wall.

Revenue That Isn't Wages: The Management-Fee Model

Management fee on bookings

The third structural decision is the one founders get backwards most often: how the money flows.

We took a 10-15% management fee on bookings, plus listing fees. We did not pay providers a wage and mark up the service.

That distinction is legal, not just accounting. It's the difference between a marketplace and an employer.

Listing fees and why the mix matters

Here's the logic. If you collect the full payment from the client and then pay out a wage to the worker, you look exactly like an employer. You're setting compensation. You're the source of their income. A regulator sees a payroll relationship wearing a costume.

Employer model vs Marketplace model - how cash flow determines legal classification

But if the provider earns directly from the client, and the marketplace earns a transparent fee for facilitating the connection, the picture flips. The provider is the business owner. The marketplace is the venue charging for access and tools. The listing fees reinforce that the platform is a service to the provider, not the employer of the provider.

So the cash-flow design was deliberate: the provider gets paid by the client, the marketplace skims a defined service fee, and there are no W2 mechanics anywhere in the system. No tax withholding. No payroll cycles. No employer-side benefits machinery.

Revenue architecture is a compliance decision. I've seen this exact dynamic in every regulated industry I rebuilt on AI, where how money moves through the system determines what licenses, structures, and exposures apply.

The critical sequencing point: I decided the fee structure before designing the payment flow. The code had to enforce the legal model, not the other way around. If I'd wired up Stripe first and figured out compliance after, I'd have built a payment system that quietly made us the employer, and unwinding that means rebuilding the financial core of the product.

Why I Made These Calls Before Writing Code

Step back and look at what happened here. The booking flow, the payments integration, the provider onboarding, the insurance verification, all of it was shaped by legal structure decided up front.

The three structural decisions made before writing code

That's the meta-lesson, and it's the one skeptical founders need to hear.

If I'd built the obvious "easy" version, the one every first-time founder sketches on a whiteboard, it would have looked great. Set the rates. Assign the best available provider. Pay them out. Clean, simple, intuitive.

And secretly an unlicensed staffing agency with a six-figure tax liability accruing from day one. A beautiful product sitting on a model that fails the ABC test on every prong.

The easy version is easy because it ignores the constraint that actually matters.

Now the honest limitations. I'm not a lawyer. You need one for your specific situation, full stop. AB5 has carve-outs for certain professions, the law keeps shifting, and there's ongoing litigation and ballot-measure history (Prop 22 reshaped the rules for some gig work and parts of it have been fought over in court for years). What was settled last year may not be settled next year.

So I'm not telling you what your structure should be. I'm telling you that the structure is a load-bearing question, and load-bearing questions get answered before the build, not after.

That's the founder's actual job. Not knowing every answer. Knowing which questions hold up the building. This is the same pattern I've seen across every regulated space I've worked in, from standing up a regulated brand to financial and health products. The constraint comes first. The product is built to fit it.

Get the Structure Right Before You Get the Product Right

Here's what I want you to take away. In any services marketplace that touches California, the legal structure isn't a footnote in the appendix. It's the foundation the entire product sits on.

Legal structure as the foundation the product sits on

The marketplace model instead of an employer relationship. Providers as independent contractors carrying their own insurance. Fee-based revenue instead of wages. Every one of those looks like a legal decision. They're actually product decisions in disguise, because they dictate how the booking flow works, how money moves, and what the onboarding has to capture.

I build inside these constraints, not around them. That means the structure shows up in the code on day one, instead of getting bolted on after a cease-and-desist letter forces a panicked rebuild. The cheap insurance is doing it right the first time. The expensive version is finding out you did it wrong once you have revenue, providers, and a regulator's attention.

If you're standing up a two-sided marketplace, a regulated service, or anything where the business model itself carries legal weight, that's exactly the kind of thing I help founders work through before they build. We pressure-test the model first. Let's pressure-test your model before the code locks in a structure you can't easily undo.

Get the structure right, and the product gets a foundation it can actually stand on.

Thinking about AI for your business?

If this resonated, let's have a conversation. I do free 30-minute discovery calls where we look at your operations and find where AI could actually move the needle, not where it sounds impressive in a board deck.

Book a Discovery Call