Safar
Travel discovery and planning for Armenia in English, Russian and Persian. A traveller starts from a journey, a single day, or dates and bookings they already have, and an approved local partner fulfils the trip.
A first-time visitor can shape a trip and keep it without creating an account, then ask a human desk when the catalogue is not enough. Nothing is booked or paid until they confirm.
Problem
Someone planning a first trip to Armenia has to choose between booking marketplaces that treat it as inventory and individual operators' sites that each show one piece. Neither helps them decide what the trip should be, and neither is honest about who will actually deliver it.
Role
- Product owner — set the priority, the traveller journeys and the decisions the build may not change
- Wrote the product definition and the operating documents
- Directed AI-assisted implementation, with review triggered for trust, accessibility and localisation risks, and approved every release
Approach
- Organised the product around six traveller jobs: arrive with a clear first move, orient by destination and need, browse a place, judge a listing honestly, keep a trip without logging in, and ask a person
- Made journeys the starting point rather than a search box, with single days and fixed-constraint planning as the other two routes in
- Kept the trip list account-free so a traveller can plan before giving any contact details
- Separated design from fulfilment: Safar shapes the days, an approved local partner delivers them, and the partner is disclosed before the traveller confirms or pays
- Built an internal Trip Desk so every request lands in one operator workflow, with a written service level and a failure playbook for transfers
- Wrote the V1 product definition, operating procedures and launch gates before commercial launch, and froze the architecture until a recorded decision changes it
Outcomes
- Live at safar.am in three languages
- Journeys of five, seven and nine days and a winter journey, alongside single-day experiences
- Request flows for trips and airport transfers, with an operator desk behind them
- A pre-deployment check that fails when required production configuration is missing
- Three ways in: a shaped multi-day journey, single days that combine, or a trip built around flights and hotels the traveller has already fixed
- English, Russian and Persian routes, with an intentional right-to-left layout for Persian rather than a mirrored one
- A password-protected Trip Desk gives operators the lead and transfer workflows
- My Trip saves on the device with no account, and can be shared as a private server-backed link
- Requests are stored in the database first; the notification webhook is only a notification, so a failed message cannot lose a lead
- Fulfilment is by an approved local partner, named to the traveller before confirmation and payment
What I refused to build
These constraints are part of the engineering signal: the work stayed useful because the unsafe shortcut paths stayed out.
- R-01Payments in the first version — nothing is charged through the site
- R-02Invented hours, prices, ratings or availability — a listing shows a field only when the record has it
- R-03A confirmation that pretends — without a live database, forms return a clearly labelled preview, never a false 'request received'
- R-04Paid placement mixed into recommendations — sponsored sections are labelled and kept apart from editorial ones
Stack
Working with Asadi Labs
This is the kind of system Asadi Labs builds and runs for clients: fintech systems where product direction, architecture, execution, and governance all have to line up.