Renuir: reuniting people with their lost belongings
I own product strategy and MVP definition for Renuir, a multi-sided recovery platform for Europe's lost-and-found ecosystem: matching, three-stage verification, notifications and partner API workflows. I set the scope, the KPI framework and the release requirements, and led the design of the 47 screens that carry them across B2C and B2B.
Most lost items are never returned
People who lose personal belongings in public spaces, transit, and events, plus finders who want to return items without hassle
A mobile platform that connects lost items with their owners through AI matching, ownership verification, and coordinated return
Immediately after losing or finding an item, when urgency is highest and existing systems fail to provide any clear next step
Public transit, airports, events, cafes, and shared spaces across European cities
Most lost items are never returned. Lost-and-found offices operate in silos, finders have no clear way to return items, and no cross-organization protocol exists
Camera-first item reporting, AI photo matching, multi-step ownership verification, safe meetup coordination, and shipping integration
Most lost items are never returned
From our interviews and operator conversations: most lost items in European transit systems are never reunited with their owners, because the process is fragmented across every organisation that touches them.
People give up on day one
Interviewees described stopping the active search within the first day, worn down by friction in reporting and searching.
No unified platform exists
Our competitive scan found no protocol-layer solution that standardizes lost-and-found across organizations and countries.
The blueprint located the handoffs
Our service blueprint surfaced the moments where items get permanently lost in the current system.
6 weeks of deep research
I spent 6 weeks in discovery before designing a single screen. I interviewed people who lost items, people who found items, and lost-and-found office operators. I mapped the EU regulatory landscape to understand legal requirements around found property.
User interviews (n=16)
Spoke with 8 "losers" (people who lost items), 4 "finders," and 4 lost-and-found operators across three European cities. Key finding: the emotional distress of losing items is severely underestimated. It is not just about the object's monetary value.
Competitive analysis
Analyzed 8 solutions (iLost, Tile, Foundit, and a major transit operator lost-property service). Most were device-only (Tile) or single-organization (iLost). None offered a true cross-organization protocol. This validated our infrastructure-first approach.
Regulatory mapping
National found-property law (BGB sections 965-984) defines legal obligations for finders. EU GDPR adds complexity around sharing personal data between parties. These constraints directly shaped the ownership verification and data-handling flows.
Service blueprint
Created an end-to-end blueprint mapping frontstage interactions, backstage processes, and support systems. This revealed the 7 critical handoff points where items typically get lost in the current system.
Three user types, fundamentally different trust needs
Sara, 28
Realises the loss hours later, with no idea where to start looking.
- Goals
- Report lost items quickly, get notified if found, verify and recover securely
- Frustrations
- No centralized search, emotional stress, privacy concerns about sharing personal info with strangers
- Trust need
- High. Needs to know the platform and the finder are both legitimate
Marcus, 35
Wants to return a bag found in a cafe without the handover being awkward or risky.
- Goals
- Return items without hassle or obligation, no need to meet strangers, feel good about helping
- Frustrations
- Social awkwardness, liability concerns, time commitment uncertainty
- Trust need
- Medium. Wants assurance they will not be blamed for theft or damage
Katja, 42
Runs a lost-and-found office full of unclaimed items and needs something that fits existing processes.
- Goals
- Reduce unclaimed items, automate matching, integrate with existing tools
- Frustrations
- Manual processes, storage costs, regulatory compliance burden
- Trust need
- Institutional. Needs data security proof and GDPR compliance
The question that decided what got built
A recovery platform can absorb unlimited feature work, so every candidate went against one question.
What is the minimum viable trust? The smallest set of features that makes a stranger comfortable handing your belongings back to you. Not the most trust achievable, the least that still gets the item moving.
Admitted: three-stage ownership verification
The most complex thing in the MVP and the one feature it cannot launch without. Found-property law requires proof before release. Without it the platform helps strangers take each other's property.
Admitted: the handover code
A small, cheap mechanic that closes the loop. Both sides need a moment where the exchange is confirmed and the claim is settled, or neither side knows the transaction ended.
Admitted: the match confidence score
Not scoped as a trust feature at first. Testing moved it: 5 of 6 moderated testers named it as the thing that convinced them the system was working.
Cut back: the ownership upload
The first version asked for several proof types at once. 21% of testers struggled with it. More proof is more trust in theory; in practice it was the step people abandoned. Reduced to one proof type at a time.
Three of those four are the expensive answer. The rule was not there to shrink the product, it was there to stop it growing where growth did not buy trust.
What this product has to move
Usability scores tell you whether a screen works, not whether a recovery platform does. The loop only succeeds when an item changes hands, so the KPI framework is built on the loop rather than the interface.
The outcome
Verified returns. The number the product exists to move. A match that is never collected is not a return, so it is counted at handover.
Time to match. Interviewees gave up the active search within the first day, so the useful window is short.
The operating cost
Partner processing time. Offices carry the storage and the manual matching. If the platform does not cut time per item, it is one more system to maintain.
Support demand per return. People contact support the moment they are unsure, so the volume tracks how well the flow explains itself.
The first two are the user case, the last two the partner case. A version that returns more items by pushing work onto operators does not survive contact with the people running it.
The return loop: balancing speed with security
Fast enough that people do not give up, secure enough that ownership is proven before anything is released.
Walking the return loop
One loop, six moments, in order: from realising an item is gone to getting it back, including the path where the claim is refused.
Reporting a loss, camera first
Onboarding communicates three value props through illustrated screens: report, match, return. Sign-up is email plus OTP for simplicity, with Google SSO as the alternative. Reporting is camera-first: photograph the item, add details, pin the location, post. The person doing this has just lost something, so the flow asks for the least it can get away with.
Onboarding, then a camera-first flow to report an item.
The match, and a private channel
When the AI finds a candidate, both sides see a confidence score rather than a bare yes. In-app messaging coordinates the return without either party sharing a phone number or address, the biggest objection finders raised in research.
Match confidence, then a private chat that never exposes contact details.
Proving the item is yours
Ownership is established with serial numbers, receipts, photos, or warranty documents, and the finder reviews the proof before approving. This is the step that carries the most fraud risk and, as testing later showed, the most friction.
The full verification flow: claim, evidence, review, decision.
Handing it over in person
For an in-person return the app suggests a safe public place and confirms the handover with a four-digit code, so neither person has to judge a stranger on the spot. The code is the proof the item changed hands.
A suggested public location, then a four-digit code to confirm the handover.
Or shipping it, tracked
Not everyone wants to meet. The second path ships through a delivery partner with live tracking, so a finder can return an item without meeting the owner.
The shipping path, for finders who would rather not meet anyone.
When the evidence does not add up
A claim can be wrong, or dishonest. The finder can decline and the claimant is told, rather than left guessing. This is the moment the platform either protects both sides or makes an enemy of one.
The decline path, written to protect the finder without accusing the claimant.
Two rounds: moderated (n=6) and unmoderated (n=18)
Tested with people who had recently lost items, frequent public transit users, and hostel travelers. Used both moderated sessions for qualitative depth and Maze for quantitative validation.
Task completion
Key metrics
- NPS, moderated round
- +52
- Median onboarding time
- 38 seconds
- Median report time
- 72 seconds
Ownership verification too complex on mobile
21% struggled with document upload. The multi-select interface confused users. Simplified to progressive disclosure: one proof type at a time with clear examples.
Meeting location suggestions needed context
Users loved safe meeting spots but wanted to know why they were "safe." Added rationale labels: "Police station: public, CCTV, staff present."
Match confidence score built immediate trust
5 of the 6 moderated testers said the "98% match" indicator gave them confidence the system was working. Without it, users questioned whether the match was real.
Handover code needed better error recovery
Wrong code error was unclear. Added: "Code does not match. Ask the other person to show their code screen" with retry.
Designing for trust is the hardest problem
Strangers hand each other belongings through this product, so the interface has to move the item and give both sides a reason to believe the other will show up. No single screen carries that. It comes from the wording on the claim form, the proof asked for, the meetup place suggested and the code exchanged at handover.
A scope rule is only useful if it can say no
The minimum viable trust question earned its place because it rejected things I wanted to build. A prioritisation framework that only ever confirms the roadmap is a description of the roadmap, not a rule.
One component library, three surfaces
The mobile app, the B2B admin dashboard and the API documentation run off the same token set, so new flows are assembled in hours rather than weeks.
The regulation and the product wanted the same thing
Found-property law and GDPR looked like obstacles. Both push where the product already needed to go: prove ownership before release, hold no more personal data than the handover needs.