Marketplace and SaaS: why Koora is both

Most software companies pick a lane. You are either a marketplace, matching two sides and taking a cut of the transaction, the model care platforms like Mable and HireUp have built well, or you are a tool, charging one side a subscription for software that does a job. The advice you hear is to choose, because the two have different physics. Marketplaces live and die on liquidity. Tools live and die on retention and feature depth. Trying to be both is usually a way to be neither.

Koora is being built to be both, on purpose. Not because we want to dodge the choice, but because the care sector breaks the assumption underneath it. The thing a worker owns and the thing a provider pays for are the same underlying object, viewed from two ends. So this essay is the honest version of why we think the network and the software are not two products bolted together, but one product that happens to have two faces.

The two faces of one object

A Career Passport is held by the worker. It is the place their police check, their working with children check, their qualifications, their first aid currency and their NDIS screening live. It travels with them. When they move between employers, agencies or sectors, the credentials do not get re-collected from scratch. That is the network side. The value compounds as more of a worker's working life flows through the one record, and as more of the places they work can read from it.

Provider compliance tracking is the software a care organisation pays for. It is the dashboard that tells an HR or workforce lead who is compliant today, what is expiring, and what evidence exists for an audit. That is the SaaS side. The value compounds as the tool gets deeper: better expiry logic, better reporting, better fit to the strengthened Aged Care Quality Standards and the realities of working across multiple providers.

Here is the part that matters. The worker's Passport and the provider's dashboard are reading the same credential. When a worker updates their police check, the provider does not chase a fresh copy. When a provider's requirements change, the worker sees exactly what is now missing. One object, two views. That is not a coincidence of design. It is the whole thesis.

More than an app: the layers underneath

When people first meet Koora they reach for a familiar category: is it a job board, a background check, an HR tool. The more useful way to see it is as a few layers of infrastructure that the care sector has never had in one place:

• An identity layer: confirming who a worker is, including identity documents verified against the Document Verification Service.
• A compliance layer: which credentials are current, what is expiring, and what evidence an audit will ask for.
• A reputation layer: a portable record of how a worker has actually performed, owned by them. Frontline care has never had a good home for this. LinkedIn is built for desk jobs, and traditional references are slow and inconsistent. This layer is on our roadmap, not shipped, and we are building it as two-way verified feedback rather than star ratings.
• A hiring layer: faster, lower-friction onboarding, because the three layers underneath are already in place.

Seen as one stack rather than four separate products, the marketplace-and-SaaS combination stops looking confused and starts looking like plumbing. Most of the sector still runs these layers on email, spreadsheets and filing cabinets, re-done at every provider. Bringing them into one worker-held record is the work.

If there is durable advantage in any of this, it will not be a single feature, which anyone can copy. It is the verified working history that accumulates in worker-held records over time, and the network of providers that read from them. Both compound, slowly, and neither can be reproduced overnight. We are nowhere near that yet, and saying so plainly matters more than the claim would.

Why the network makes the software better

A compliance tool that only holds what one employer collected is a filing cabinet with search. It is genuinely useful, and most of the sector is not even at that bar yet. But its ceiling is low, because it only knows what that one provider asked for and gathered.

The moment the underlying credential is worker-held and portable, the software changes character. A provider onboarding a worker who already has a populated Passport is not starting from an empty form. The screening that another provider already sighted, the qualification already reviewed, the currency already tracked, can carry across rather than being re-done. The provider still keeps their legal duty. Koora pre-clears; the provider's authorised person still sights and decides. But the software is doing a different job when the data behind it is shared infrastructure rather than a private silo.

Why the software makes the network worth joining

The reverse is just as important, and it is where a lot of "portable credential" ideas quietly fail. A worker will not maintain a Passport that does nothing for them today. Asking people to upload documents for a future where employers might one day read them is a cold start that never warms up.

The provider software is what gives the worker a reason to keep the Passport current right now. The credentials a worker assembles are immediately useful because real providers are using the tool to onboard and monitor. The worker maintains the Passport because it gets them through onboarding faster and keeps them eligible to work, not because of a promise about network effects. The SaaS demand creates the gravity that makes the worker-held record worth maintaining. Without that, the network is a museum.

The honest caveats

We are pre-launch and small, so I will not pretend the flywheel is already spinning. It is a thesis we are building toward, not a result we can point to. The classic risk of two-sided products is real: you can spend years half-serving both sides and fully serving neither. Our bet to manage that is sequencing. The provider tool has to be genuinely good as standalone software first, valuable even to an organisation that never sees the network benefit, because that is what earns the right to accumulate worker-held credentials at all.

I also want to be careful about the analogy reflex. It is tempting to reach for "the Stripe of care" or "the LinkedIn of credentials". Those comparisons flatter more than they explain, and we have not earned them. The honest framing is narrower: in a sector where the same screening gets collected over and over, where workers move constantly and providers carry heavy compliance duties, a worker-held record and a provider tool reinforce each other in a way that a pure marketplace or a pure SaaS product cannot. Recognition features, richer verified feedback, and deeper portability are roadmap, not shipped reality.

What this commits us to

Being both faces means we cannot optimise one side at the cost of the other. We cannot lock a worker's credentials so providers have to pay a toll to read them, because then the worker is not really holding their own record. We cannot make the provider tool depend on network density that does not exist yet, because then early customers get nothing. The discipline is to keep the object honestly worker-owned and the software honestly standalone-useful, and let the connection between them do the compounding over time.

That is the harder path, and probably the slower one. We think it is the only version that actually serves the people doing the work. We are here to uplift care, and care is delivered by people who deserve to own their own working history rather than re-prove it at every door. Building the marketplace and the SaaS as one object is how we try to honour both ends of that at once.