From listing to handover

A parcel has three people behind it

Imagine you want to send a book to someone close to you. A traveler is already going in the right direction. You find each other, but there are still questions: what is inside, when can you meet, and who will collect it?

I'm building RÓSA around those questions. Here's the intended journey, with a simplified example rather than a real delivery story.

Before anyone takes the parcel

• The sender describes the item and adds photos that show its contents and condition.
• The traveler publishes a route and available capacity, then checks whether the parcel fits the trip.
• The recipient joins the agreement and confirms the receiving arrangements.

A listing can start without a named recipient. The recipient needs to join before the three-person agreement can be completed. One account can send, travel and receive in different situations.

Why two handover codes?

There are two different moments to confirm: the sender gives the item to the traveler, and the traveler gives it to the recipient. RÓSA's test flow uses a separate one-time code for each handover.

The code records a confirmation. It does not inspect the contents or prove that an item is undamaged. People still need to check the item and record its condition.

And if plans change?

Before agreement, listing edits have a history. After agreement, an update should be visible as a comment rather than silently changing what people accepted. A delayed trip and a damaged item need different responses; the return and dispute procedures are still being developed.

Where this stands: the audit of 11 September 2026 found these core rules in the test product. Real payments and document verification are not connected, and readiness for actual deliveries is not confirmed. This explains the product being built, not an invitation to hand over a parcel today.

For me, the useful part is keeping all three people in the same conversation about what happens next.