Over the last decade, the sharing economy changed how people access almost everything. Renting a stranger’s apartment through a phone feels ordinary now: search, compare, book, and let yourself in, from anywhere, in minutes.
Car rental never made that jump. A traveler who lands at Málaga at midnight can unlock an apartment, order dinner, and book a table before leaving the terminal — then spend 30 or 40 minutes in a rental queue for the one thing that gets them out of the airport, repeating information they already submitted online and initialling a contract nobody reads.
Juuh is our answer to that gap: a peer-to-peer car sharing marketplace that connects people who own vehicles with people who need one, launching across Andalusia, Spain, in September 2026. Renewator designed and built the platform end to end — the website and applications, host and renter accounts, listings, search, availability calendars, booking, online payments, digital documentation, driver verification and GPS-based telematics.
See it at juuh.com.
This article is not a launch announcement. It is a builder’s write-up of the problems a peer-to-peer rental marketplace actually has to solve — trust, fraud, protection, liquidity — and the decisions we made on each, including the ones that are still open.
Why car rental stayed behind
Flights, hotels and apartments were digitised because the asset can be handed over without anyone touching it. A booking code opens a lockbox. Nothing needs to be inspected, fuelled, insured against collision, or returned in the condition it left.
A car is the opposite. It is a high-value asset that moves, gets damaged, accumulates fines, needs a licensed driver, and carries liability that follows the owner. Every one of those facts is a reason the incumbent industry built its process around a counter, a queue and a stack of paper. The paperwork is not laziness; it is risk management with the wrong tools.
That is why the friction survives even where the front end is modern. You can book online and still find that:
- The counter re-checks the licence you already uploaded;
- The contract, the deposit hold and the damage waiver are decided in person, under time pressure;
- The fleet is whatever the branch has, not what you chose;
- Return means a physical inspection by someone whose incentives are not yours.
Andalusia makes the mismatch sharper than most places. Eight provinces, a tourism curve that swings hard between a packed Costa del Sol summer and a quiet February, and demand concentrated around a handful of arrival points — Málaga, Seville, Granada, Jerez, Almería. In peak weeks the region needs far more cars than in the off-season, and the traditional answer is to own the peak: buy fleet, park it eleven months a year, and price the scarcity back to the customer.
Meanwhile, the cars that could absorb that peak already exist. They are parked at the airport in the long-stay lot, owned by residents who are away, or simply sitting outside a house in Fuengirola doing nothing for weeks. The supply problem is not a shortage of vehicles. It is a matching problem, and matching problems are software.
What we actually built
The technology platform is complete. As of today it covers the full rental journey:
- Accounts for both sides. Hosts list and manage vehicles; renters manage bookings, documents and payment methods.
- Listings, search and availability calendars. A host controls when a car is available; a renter searches real availability, not a call-centre promise.
- Booking and online payments. The commercial transaction is closed in the app, before anyone meets.
- Digital documentation. Rental agreements, condition records and the paper trail a dispute would need, generated and stored digitally.
- Driver verification. Identity and licence checks happen at onboarding, not at handover.
- GPS-based telematics. Vehicle location and trip events, available to the platform for safety and dispute resolution.
The design principle behind that list is simple: everything that can be decided before the two people meet should already be decided. The counter exists because verification, payment, contract and liability were all resolved at the last possible moment, in person. Move each of those upstream and the physical handover shrinks to what it should be — handing over a key.
The four hard problems of a peer-to-peer rental marketplace
Any team that proposes “Airbnb for cars” is signing up for four problems that accommodation platforms either do not have or have in a much milder form. They are worth naming explicitly, because they are what separates a marketplace that survives its first bad month from one that does not.
1. Trust and adverse selection
In a two-sided marketplace, the first users on each side are the ones with the least to lose. Left alone, that skews supply toward the worst cars and demand toward the riskiest drivers — the classic adverse selection spiral that has killed more marketplaces than any competitor.
Juuh’s answer is a Trust Score: a calculated reputation signal for participants, computed from verification status, platform history and behavioural signals rather than from star ratings alone. Star ratings are slow, sparse and polite; a score built on what people actually do reacts faster and lies less.
The uncomfortable part of any scoring system is the cold start. On day one there is no history to score. This is the single most underestimated requirement in AI-adjacent products, and we have written about it before in our data requirements checklist for AI projects: a model is a claim about data you must already have. In practice it means the launch configuration leans on hard verification and conservative defaults, and the learned signals earn their weight as volume arrives — not the other way round.
2. Fraud and identity
A rental marketplace is a target because the payoff is a physical car. The attacks are well known — synthetic or stolen identities, licence documents that do not belong to the person holding the phone, payment instruments that will be charged back after the vehicle is gone, accounts that behave normally until the one booking that matters.
This is why driver verification and risk assessment are platform functions, not a checkbox on a form. Verification runs at onboarding so a fraudulent account fails long before a host is standing in a car park handing over keys, and risk assessment scores the booking itself, not just the account.
3. Protection and claims — the honest part
Here is the part most pre-launch write-ups quietly skip. Insurance is the load-bearing wall of peer-to-peer car sharing. A host lends an asset worth tens of thousands of euros to a stranger; the entire proposition depends on what happens when that stranger reverses into a bollard.
Juuh’s protection and claims infrastructure — the flows, the documentation, the evidence trail, the escalation path — is designed and built. The insurance coverage behind it is not yet activated. Finalising that solution is what stands between the current pre-launch stage and commercial operations, and it is deliberately a blocker rather than a fast-follow. Launching a rental marketplace on an unresolved insurance position would not be a growth decision; it would be an uninsured liability transferred onto the hosts who trusted the platform first.
We would rather publish that sentence than a vaguer one.
4. Liquidity, and why one region
Marketplaces do not scale by covering more territory. They scale by becoming reliably dense somewhere. A renter who searches and finds nothing available nearby does not come back, and a host whose car sits unbooked stops maintaining the listing. Both failures happen fastest when supply is spread thin across a wide map.
Launching across Andalusia rather than “Spain” is that lesson applied: a defined region with real internal demand, seasonal peaks worth absorbing, and enough concentration around its arrival points for search results to be non-empty in week one. The pre-launch period is spent accordingly — onboarding hosts and vehicles, so the marketplace opens with something to rent. Supply first is the unglamorous, correct order.
Where the AI actually sits
“AI-powered” is close to meaningless as a product claim in 2026, so it is worth being precise about where automation earns its place in Juuh and where it does not.
AI and algorithmic automation run in six specific operational areas:
- Risk assessment — scoring a booking before it is confirmed.
- Fraud detection — catching patterns across accounts, devices and payments that no single rule would flag.
- Trust Score calculation — the reputation signal described above.
- Telematics event analysis — turning a stream of GPS and trip data into meaningful events instead of noise.
- Dynamic pricing — reconciling seasonal demand with what a host is willing to accept.
- Vehicle ranking — deciding what a renter sees first.
Two things are notable about that list. First, none of it is a chatbot. The automation sits in operations — the decisions a growing marketplace would otherwise need to make manually, thousands of times a week, consistently, at 2 a.m. That is where machine decision-making genuinely outperforms a human team, and it is the honest use case behind most successful “AI-powered” marketplaces.
Second, the systems support decisions rather than replace judgment. Critical restrictions, disputes and incidents can be escalated for human review. That boundary is a deliberate design decision, not a limitation we intend to engineer away. An automated system that can permanently restrict a host’s account, or settle a damage claim against a renter, without a human path of appeal is not an efficient marketplace — it is a reputational incident with a delivery date. Most of the AI implementation mistakes we see in the field come from exactly this: automating a decision whose failure mode nobody costed.
Telematics: what it is for, and what it is not
GPS-based telematics is the piece that makes peer-to-peer rental defensible rather than merely convenient. It answers the questions that otherwise turn into one person’s word against another’s: where the vehicle is, when the trip actually started and ended, whether it left an agreed area, what happened around the moment of an incident.
That capability comes with an obligation. Location data about identifiable drivers is personal data under GDPR, and a marketplace operating in Spain is squarely inside that regime. The discipline is to collect it for defined purposes — safety, dispute resolution, rental status — and to keep the analysis pointed at events rather than at surveillance of a person’s day. Telematics that quietly becomes a behavioural dossier is both a compliance problem and a trust problem, and trust is the entire product.
Dynamic pricing in a seasonal market
Andalusia’s demand curve is the argument for algorithmic pricing. August on the Costa del Sol and a wet Tuesday in November are different markets, and expecting individual hosts to price both correctly is expecting them to run a revenue desk as a hobby.
Dynamic pricing and vehicle ranking work together here: pricing moves the marketplace toward clearing, ranking decides who benefits from the demand. Both need a constraint that is easy to forget in the model and expensive to forget in the market — a host who feels the algorithm priced their car against them will delist it. Supply-side trust is a pricing constraint, exactly as we argue in our guide to designing pricing tiers that convert: the number that maximises a single transaction is rarely the number that maximises the relationship.
The handover decision
At launch, vehicle and key handover happens directly between host and renter. Everything else — identity verification, booking, payment, documentation, rental status — is handled digitally through the website and applications.
That is a deliberate choice, and the most interesting product decision in the build.
The obvious “complete” version of this product is fully keyless: an app that unlocks the car, no meeting, no key. It is technically achievable, and it is a trap for a launching marketplace. It requires hardware in every vehicle, which means every host must install and maintain a device before their car can earn anything. That converts the supply side from “list your car this evening” into a logistics operation — precisely the barrier that keeps a two-sided marketplace from reaching density, which the previous section identified as the thing that actually kills it.
A human handover, by contrast, costs the platform nothing to support, works on any vehicle from day one, and quietly solves problems that keyless systems handle badly: a walk-around inspection with both people present, the moment to point out an existing scratch, a face-to-face that suppresses a surprising amount of bad behaviour on both sides.
So the sequence is: digitise everything that scales, keep the physical moment human until the marketplace is dense enough to justify hardware. This is the same reasoning we apply when helping founders decide which MVP features to build and which to cut — the cut list is where product judgment shows, and “it’s technically possible” is not a reason to ship something in version one.
What pre-launch actually means
Juuh is in its pre-launch stage. Concretely, that means three workstreams, not a countdown:
- Supply onboarding. Hosts and vehicles, so search results are worth returning to. This is the gating factor for a credible launch, not a marketing task.
- Insurance finalisation. As above — the protection and claims infrastructure is built; the coverage behind it must be activated before commercial operations begin.
- Operational readiness. The support paths, escalation routes and human review capacity that the automated layer defers to when something goes wrong. A marketplace’s reputation is set by how its worst week is handled.
There is no fourth workstream called “finish the platform,” because that part is done. That is an unusual position for a September launch, and it exists because the build was sequenced around the risk items rather than around the demo.
What we would tell a founder building something similar
A few things generalise beyond car sharing, and they are the same points we make when we are brought in to validate an idea before development starts:
- Name the load-bearing wall early. For Juuh it was insurance. Every marketplace has one — a legal, financial or logistical dependency that no amount of good software routes around. Find it in week one, because its lead time, not your development speed, sets your launch date.
- Write the automation requirements as decisions, not features. “AI-powered pricing” is not a requirement. “Given this vehicle, this date and this local demand signal, produce a price the host will accept and the renter will book” is. Our guide to writing AI requirements that work exists because this distinction is where most AI projects quietly fail.
- Decide where a human stays in the loop before you need one. Escalation designed after the first serious incident is designed in the worst possible conditions.
- Be geographically greedy last. Density first, coverage second.
- Build the boring evidence trail. Digital documentation, telematics events, condition records. Nobody demos it, and it decides every dispute you will ever have.
The point
The future of transport is not only about producing more vehicles. Cars are among the most underused assets people own — bought for the busiest hour of the week, parked for the rest of it. A marketplace that reconnects that idle capacity with the people who need it for three days is a better use of what already exists than manufacturing more of it.
Juuh is our attempt at that, starting in Andalusia in September 2026, built the way we build products for clients: the software and product design in-house, the risky parts scheduled first, and the claims in public matched to what is actually running. It joins Disho, our QR video menu for restaurants, as a product we run ourselves rather than only ship for a client.
Renting a car should not mean 40 minutes in a queue. It should be as simple as booking a place to stay: open an app, pick a car nearby, and go.
If you are building a marketplace with its own load-bearing wall — insurance, licensing, hardware, liquidity — that is the kind of problem we like. Tell us about it, and a senior engineer will give you an honest read on scope and sequencing.
