I have been rebuilding RÓSA screen by screen, and this update is the clearest picture yet of how the product is meant to work.
RÓSA connects three people around one real journey: someone who wants to send an item, someone who is already travelling, and the person who receives it. The difficult part is not drawing another listing screen. It is making sure every person understands what happens next, who is responsible at each step, and how a handover is confirmed without relying on vague messages such as ‘I gave it to her.’
One journey, three different roles
The new prototype separates the experience into three roles:
The sender creates the item listing, describes what is being sent, adds photos and agrees on the handover details.
The traveller publishes a route, finds a compatible item and confirms that the item was accepted for the journey.
The recipient follows the transfer, checks the item and provides the delivery code that the assigned traveller enters to confirm the handover.
Each person sees the information and next action that belongs to them. This removes a common source of confusion: three people may be part of the same transfer, but they should not see the same buttons or be asked to confirm the same event.
LISTING → MATCH → AGREEMENT → HANDOVER → DELIVERYFrom a public listing to a real handover
The journey begins with a public listing. A sender can show what needs to be delivered, while a traveller can publish an upcoming route. When the dates, route and item conditions fit, the conversation moves into a private transfer chat.
That chat keeps the agreement connected to the actual listing. People can discuss the meeting point, timing and item details without losing the context of what they are arranging.
After both sides agree, the transfer moves through clear stages instead of disappearing into an unstructured conversation. The prototype now shows the preparation, first handover, journey and final delivery as parts of one traceable flow.
Keeping the conversation connected to the transfer
The dashboard and private chat are designed to work together. A user can see active transfers, open the relevant conversation and return to the transfer details without searching through unrelated messages.
This matters because chat alone does not describe the state of a delivery. A message can say that two people agreed to meet, but the product still needs to know whether the item was inspected, accepted, delivered or delayed.
Why RÓSA uses two different codes
This is the most important logic in the current update.
A single confirmation code would mix two different events. The first happens when the sender gives the item to the traveller. The second happens later, often in another city or country, when the traveller gives it to the recipient.
ACCEPTANCE CODE ≠ DELIVERY CODE1. Acceptance code
The acceptance code belongs to the first handover.
The sender and traveller inspect the item together. They check that the package and its visible condition match the listing. When the handover is complete, the acceptance code records that the traveller received the item.
This code should never confirm final delivery because the recipient has not received anything yet.
2. Delivery code
The delivery code belongs to the final handover.
At the destination, the recipient checks the item before confirming receipt. The delivery code records that the traveller handed the item to the intended recipient.
The two codes represent different people, different places and different changes of responsibility. Keeping them separate makes the history of a transfer easier to understand when everything goes well and much more useful when something does not.
What the codes are designed to prevent
confirming the wrong stage of a transfer;
treating a chat message as proof of a completed handover;
using one person’s confirmation for another person’s action;
accidentally reusing an old code;
leaving people unsure whether the system recorded the handover.
The prototype treats a code as belonging to one transfer and one step. In the production design, replacing a code must invalidate the previous challenge in the same server operation. Codes are time-limited, and repeated failed attempts can pause verification before another attempt is allowed.
A safe flow also needs failure states
The success screen is only the easy part. A useful product must explain what happens when a person enters the wrong code, waits too long, requests a replacement or loses connection during confirmation.
WRONG → EXPIRED → REPLACEDThe updated screens now separate these situations:
Wrong code. The interface explains that the value does not match and allows another attempt without pretending the handover succeeded.
Expired code. The old code can no longer confirm the step. The user is directed to request a fresh one.
Paused attempts. Repeated failures do not continue forever. Verification can be temporarily paused so the situation is visible and deliberate.
Replacement code. A newly issued code replaces the previous code instead of creating two valid ways to confirm the same handover.
The main principle is simple: nobody should have to guess whether responsibility actually moved from one person to another.
What happens behind the six digits
The visible confirmation code is deliberately simple. The decision behind it is not. The following is illustrative pseudocode, not a copy of the production source. It explains the verification pipeline without exposing internal endpoints, stored values or operational security details:
AUTHORIZE → SCOPE TO TRANSFER AND STAGE → VALIDATE → CONSUME ONCE → RECORD
A number by itself does not complete a transfer. The system also checks who is signed in, which transfer is open, which handover is taking place and whether the confirmation is still valid. A correct-looking number used by the wrong participant, for another transfer or at another stage must not change the transfer status. Once a challenge succeeds, it is consumed. A repeated request returns the recorded result instead of creating a second handover, which matters when someone taps twice or loses the response after the server has already processed the first request.
Why a copied number is not enough
The confirmation is short-lived and bound to its transfer, stage and participants. The server checks the surrounding context before changing responsibility for the item. Failed attempts are limited, expired confirmations are rejected and replacing a confirmation invalidates the previous one.
These layers reduce the value of guessing, copying or replaying the visible digits. The code is still shown only during the physical meeting. It is not treated as proof of identity, payment, package contents or package condition.
Security is a property we test, not a slogan
The current prototype has passed focused domain tests for role separation, stage separation, expiry, bounded attempts, one-time use, cancellation and repeat-request handling. These are controlled software tests, not proof that the complete production system is impossible to attack.
Before real deliveries, the same rules must be enforced by the production server, verified under concurrent requests and tested across separate devices and accounts. Sensitive confirmation material must remain outside logs and public responses. Issuing, replacing and consuming a confirmation must produce one consistent server result even when a connection is interrupted.
That is the model RÓSA is building toward: a short-lived confirmation that works only inside the correct transfer context, backed by authorization, limited attempts and a single recorded handover.
What is real today, and what still needs testing
These images show an editable product prototype. They define the intended roles, screens, states and recovery paths. They are not proof that every server rule is already enforced.
Real payments and real deliveries are not active in this demonstration. Before the code system can be described as a finished security mechanism, it still needs server-side enforcement, multi-device testing, interrupted-connection tests and physical testing with separate sender, traveller and recipient accounts.
I am sharing the work at this stage because the logic is still open to improvement. If one of these steps feels unclear, or if you see a failure case that is missing, I would like to hear it. Finding that problem in the prototype is far better than finding it during a real handover.