Skip to content
All articles
Inside RÓSA

Inside the new RÓSA transfer flow

From listing to confirmed delivery: three roles, two codes, and clear recovery states.

Evgeniy Radetskiy

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. The hard part is not drawing another listing screen. It is making sure everyone understands the next action, their responsibility, and the moment an item actually moves to another person.

One journey, three different roles

Choose a participant to see their part of the transfer

01

Sender

Creates the listing, describes the item, adds photos, and agrees on the time and place of the first meeting.

Three RÓSA screens for the sender, traveler, and recipient
Each participant sees their information and next action instead of the same set of buttons.

From a public listing to a real handover

A sender shows what needs to travel while a traveler publishes an upcoming route. When the dates, direction, and conditions fit, the conversation moves into a private chat for that transfer. The agreement stays connected to the item, route, and people instead of disappearing into a stream of messages.

Explore the five stages

01

Listing

What is being sent, from where to where, when, in what condition, and under which limits.

Four RÓSA screens from creating a listing to completing delivery
Separate screens show both the result and where the person is in the process.
RÓSA mobile dashboard and private transfer chat
The dashboard and chat remain parts of the same transfer, even on a narrow screen.

Why RÓSA uses two different codes

One code would mix two different events. The first happens when the sender gives the item to the traveler. The second happens later, often in another city or country, when the traveler gives it to the recipient.

Compare the two confirmations

First meeting

Acceptance code

After inspecting the item together, the sender shows this code. It records that the traveler accepted the item, but it cannot confirm final delivery.

RÓSA acceptance-code and delivery-code screens
The two codes represent different people, places, and changes of responsibility.

What happens behind the six digits

AUTHORIZE → SCOPE TO TRANSFER AND STAGE → VALIDATE → CONSUME ONCE → RECORD

This is illustrative pseudocode, not production source. A number alone is not enough: the server must check the account, transfer, stage, participant, and expiry. Once confirmation succeeds, it is consumed. A repeated request returns the recorded result instead of creating a second handover.

A safe flow needs failure states

See how the product should respond

Wrong code

The interface explains that the value does not match and leaves the transfer state unchanged.

Wrong, expired, and replacement-code states
The success screen is easy. The quality of the flow becomes visible when something does not go to plan.

What exists today, and what still needs testing

These screens are an editable product prototype. They define roles, states, and recovery paths, but they do not prove that every rule is already enforced by the production server. Real payments and real deliveries are not active in this demonstration.

  • Verify server enforcement and concurrent requests.
  • Run the journey on separate devices and accounts for all three participants.
  • Test losing the connection before and after server confirmation.
  • Keep sensitive confirmation material out of logs and public responses.

I am sharing the work now because the logic is still open to improvement. It is better to find a confusing step or missing recovery path in the prototype than during a real handover.

All articles