Keylr: a property services marketplace where trust, dispatch and money are one system
Keylr connects UK property managers with vetted suppliers. We built the platform behind it: the dispatch engine, the trust and verification layer, the real time chat and negotiation, the payments and dispute handling, and the infrastructure it runs on.
- 100+ eligible suppliers per postcode
- 3 independent checks
- 3 network zones
- 4 dispute remedies
- 0 card details held
What the platform does
Follow one job through and the product explains itself.
Service, location, and whether it is a quoted job or a fixed price one. The property manager also says how many quotes they actually want.
Not all of them. The platform releases the job in batches until the property manager has the number of quotes they asked for, then stops.
Suppliers quote, and the two sides chat and negotiate inside the platform. What was agreed is attached to the job.
Someone whose identity and background have been checked, named on the job. The property manager is charged, the supplier is paid on the schedule that suits their business, and if something goes wrong there are four ways to put it right.
- Client
- Keylr, a UK property services marketplace
- Market
- United Kingdom
- Product
- Multi-level two-sided marketplace with an embedded payments layer
- Our scope
- Marketplace architecture, dispatch engine, trust and compliance, chat and negotiation, payments and disputes, cloud infrastructure
The one fact that shaped everything
Most marketplaces are a matching problem. This one is not.
Three things that are usually separate systems have to be one system here, because each depends on the other two.
Sending a job to a supplier is an assertion that this supplier is fit to attend a property. If clearance is not part of what makes a supplier eligible, dispatch is routing work to people nobody checked.
A verification is only worth something if the platform can say who attended, not just who won the job. In a marketplace where supplier companies pass work to subcontractors, that is not automatic.
Every dispute the payments layer has to settle is a question about what was agreed and what was delivered. If the agreement happened on somebody's phone, there is nothing to settle it with.
They did not choose the supplier, did not agree the price, in most cases have no account, and are the person whose home a stranger walks into. They are the reason the trust layer exists and they are not a customer of it.
The four decisions that mattered
If you read nothing else on this page, read this.
The engine releases suppliers in batches until the property manager has the quotes they asked for, then stops.
Verification attaches to the individual attending, not to the company that won the job.
Address and tenant details are released by job stage, not attached to the first notification.
The most consequential decision in the payments layer is about what the platform deliberately never holds.
Jobs go to a target, not to everyone
For one service in one postcode there can be more than a hundred eligible suppliers. Notify all of them and three things happen at once: suppliers are flooded with work they will mostly lose, a race forms rewarding whoever happens to be holding their phone, and the property manager is buried in quotes they never asked for. Both naive fixes answer the wrong question. The right question is how many quotes the property manager actually wants.
The property manager sets how many quotes they want. The engine releases to a first batch of best-fit suppliers, counts quotes returned rather than suppliers notified, and releases a next batch only if the target has not been met. Once it is, releasing stops.
They are dropped once the window closes and the next best-fit supplier is pulled in. One slow supplier no longer stalls a job, and a slot held by someone who never intended to quote is not a slot lost.
The engine reroutes, finds and notifies replacements, and alerts the property manager. The loop runs asynchronously, so a dense postcode costs the same request time as a sparse one.
The check follows the person through the door
Suppliers enter occupied homes. Often with a tenant present. Sometimes alone, with a key. Three checks run at onboarding: a background check, identity verification, and trade accreditation. Then the part that is harder than it looks.
Is the person who was checked the same person who turns up?
Keylr is deliberately a multi-level marketplace. Suppliers are frequently companies that pass work to their own subcontractors. With company-level verification plus a delegation model, the default answer is no. A company passed its checks. A different individual attends. Company accreditation is not a background check on a human being.
Each has their own record and their own checks, rather than being typed into a form by the company that hired them.
A supplier company can only send a job to a subcontractor whose checks are current. The delegation is blocked at assignment rather than flagged in a report afterwards, which is the difference between a control and a metric.
Not only who was awarded. A property manager can tell the tenant who is coming without making a phone call.
Clearance carries an expiry. A supplier with an out of date check does not appear with a stale badge. They do not appear. The dispatch engine reads trust state, so decision one and decision two are one system.
The chain of custody survives delegation, which is the only version of a trust claim that holds up when it is tested.
Compliance is enforced when work is assigned rather than reviewed after an incident. Nobody runs a monthly report to find lapsed suppliers, because a lapsed supplier is not in the pool to be found.
The property manager can answer for who is in the building. They carry the duty of care to the tenant, and the platform gives them a name rather than a company and a hope.
Trust becomes the moat rather than a badge. A marketplace that cannot evidence who attends is a directory with a payment button, and directories do not defend a position.
A supplier learns the address when they need to go there
A batch of suppliers is notified about a job. One wins it. The rest have no reason to ever know the address. That sounds obvious, and it is routinely not how marketplaces are built, because it is easier to attach the full job record to the notification and let the interface decide what to show.
The consequence: quoting becomes a way to harvest addresses. A supplier who never intends to quote can register, sit in the eligible pool, and accumulate addresses of occupied homes across a postcode.
Service required, job description and approximate area. Enough to price the work. Not enough to find the building.
Exact address and tenant name released to the supplier who won it, and to nobody else.
Tenant contact details and access instructions available to the individual attending, and withdrawn afterwards.
The job stays in that supplier's history. Contact details and entry instructions do not.
Nineteen suppliers never learn where the property is. The address reaches one company, at the point they have a reason for it.
Registering as a supplier stops being a data collection strategy. Sitting in the eligible pool without quoting yields nothing worth having.
The property manager's duty of care is supported rather than assumed. They can tell a tenant who is coming and when, and know the platform did not hand that tenant's details to a hundred strangers.
Withdrawal is automatic. Contact details and entry instructions leave a supplier's view when the work is done, rather than sitting in a job history nobody revisits until it leaks.
Money moves through the platform, card data does not
A marketplace moving money between two commercial parties has to handle payouts, refunds and disputes cleanly. It also has to decide how much of the payment problem it wants to own. Every design that touches cardholder data expands the compliance surface permanently.
Captured by the payment provider and never by Keylr. Supplier bank credentials sit with the provider too. What the platform holds is references and intent: which job was charged and for how much.
The amount charged comes from the figure negotiated and recorded against the job, rather than from anything a browser submits.
Remedy the work, issue a credit note, refund part, or refund in full. A marketplace whose only dispute outcome is a full refund teaches both sides that raising one is a fight.
Fortnightly, monthly or instant, with UK payment methods. A sole trader and a facilities company have genuinely different cash flow needs, and offering one cadence is choosing which of them to serve.
The controls underneath
Four categories of data sit in this platform that no reasonable person would put in one place: criminal record outcomes, identity documents, addresses of occupied homes, and payment instruction. They are separated at the network level rather than sharing one environment.
Marketplace and dispatch carry the highest traffic and the largest attack surface, and are the least sensitive. Trust and identity carry background check outcomes. Payments carry the money orchestration. Volume and exposure live apart.
A single query can traverse from a job to the supplier to the subcontractor to the payout. The network cannot see inside that traversal, so the subnet boundary is not the control that matters at that point.
If read access came from a role, the engine's batching would be decorative. Deriving it from dispatch state means the marketplace is not enumerable. Nobody can sample what a property manager is putting out or at what price.
Application components hold only the permissions they need. No administrative credential exists in the application. Credentials and provider secrets retrieved at runtime, never embedded, so they can be rotated without a deployment.
The marketplace needs to answer one question at assignment: is this individual currently cleared? That is answerable from an outcome, a reference, a date and an expiry. Holding the underlying disclosure content adds no capability and creates a permanent liability.
Trust state changes, job assignment, and money movement are logged with actor and timestamp. These are the three that get questioned after an incident, and a trail assembled retrospectively is not a trail.
The constraints we designed around
Platforms that carry real volume across real integrations meet constraints. Some belong to partners who will not change their systems for you. Some appear when a threshold is crossed. Some come from the industry itself.
Building for all of them on day one is not prudence, it is waste. The work is knowing which to design for up front, which to instrument and address when they become real, and which are somebody else's decision to be routed around cleanly.
Routine work has a known price and does not need six suppliers competing. Everything else does. The obvious build is two products in one codebase, which is how a platform ends up with two of everything.
The platform's value is only visible when it is full of real jobs, real properties and real supplier activity. A synthetic dataset solves confidentiality and creates a credibility problem.
Parts of the marketplace have to be reachable by anyone with a link. That is the product. It also means those surfaces attract crawlers, scrapers and automated collectors, and on shared infrastructure that load is paid for by every customer.
Property managers who bring more work expect better terms, and the usual mechanism is a negotiation nobody initiates.
The impact, depending on your job
If you run the business
Trust is the moat. Anyone can build a listings site. What is hard to copy is a verified supply side where the platform can name who attended, which is what lets a property manager put a stranger in a tenant's home and answer for it afterwards.
The dispatch engine protects the supply side, and supply is the side that leaves. Suppliers who never win stop answering, and the platform runs out of quotes before it runs out of demand.
Payments make this the transaction venue rather than an introduction service. A marketplace that only introduces gets disintermediated on the second job. Holding the negotiation, the record and the money is what keeps the second job on the platform.
If you run engineering
The vetting chain is the part worth your attention, because it is the part that is easy to get almost right. Company level verification plus a delegation model means the person checked and the person attending are different people by default, and closing that means treating subcontractors as users and assignment as the enforcement point.
Dispatch state as the source of read authorisation. Verification held as a verdict rather than a document. Authorisation per field where a single query legitimately crosses zones.
If you run a delivery team
Most of what is on this page came from decisions about where complexity should live. Disclosure rules hang off job states the engine already maintains. The four dispute remedies run through one reconciliation path. Fixed price and quoted jobs share one state machine.
That is what keeps a team shipping features in year two rather than maintaining a folder of special cases.
If you own the numbers
The compliance surface is permanently smaller because no cardholder data is held, which removes an audit scope you would otherwise carry every year.
Disputes cost less to resolve. Four graduated remedies mean most disagreements end in a remedy or a credit note rather than a full refund, which keeps value inside the relationship.
Supplier retention is a payout decision as much as a product one, and flexible schedules cost the platform nothing while mattering considerably to a sole trader.
Volume discounts reach everyone who earned them, which is more predictable to model than a discount claimed only by customers who ask.
Built with
We name the layers rather than the suppliers on the data path, because a supplier map is our client's exposure rather than our credential. Full detail available under NDA.
More case studies
View all case studiesAQYR — recruitment platform
One platform. Three user groups. Hard multi-tenant separation.
Read case studyInvestor Relations for ASX — investor relations
Multi-tenant IR platform for ASX-listed companies.
Read case studyBonds — relationship wellness
A two-person platform where privacy is a data-layer property.
Read case studyBuilding a marketplace where trust, dispatch and money are the same problem?
Tell us what you're building, and we'll tell you honestly how we'd approach it.