Busbook
An online bus ticketing platform for Georgia — route search, schedules, seat selection, and secure online payments in a fully responsive web app.
My Role
Lead Front-End Developer — led front-end delivery: the search and booking flows, interactive seat selection, payment integration UX, and the responsive implementation.
Project Type
Client Project — passenger transport booking platform.
Tools Used
Front-end architecture, interactive seat maps, payment gateway integration, multi-language UI (ka/en), responsive implementation
Live Link
https://demo.busbook.ge/user
Problem & Solutions
Booking a Seat, Not Just a Ticket
Problem
Riders did not want a generic ticket — they wanted their seat, which means live availability rendered per departure, not a static form.
Solution
An interactive seat-selection interface synced with route and schedule data lets passengers see the bus and claim the exact seat they will sit in.
Payments People Trust
Problem
Online card payments succeed or fail on trust — and on flaky mobile connections, an ambiguous payment state is worse than a failed one.
Solution
A hardened payment flow with explicit pending, failure, and success states keeps every passenger certain of exactly where their money and ticket stand.
Search That Works on a Phone at the Station
Problem
Most bookings happen on mobile, often on weak connections at the bus station — a search form that demands perfect input or a heavy results page loses the passenger to the ticket counter.
Solution
The route search is a three-field form with deep-linkable results (origin, destination, and date live in the URL), a bilingual ka/en interface, and lightweight result cards, so a passenger can find and share a departure in a few taps.
Architecture
Angular app with deep-linkable route search and a live seat map; the booking API holds seats and confirms tickets after the payment gateway responds.
Decision log
The calls that shaped the build — what was decided, why, and what it cost.
Search state lives in the URL
Decision. Keep origin, destination, and date in the query string of the results page.
Context. Passengers share departures and refresh pages on weak mobile connections at the station.
Consequence. Results are shareable and survive a refresh or the back button; no client-only state to lose.
Explicit payment states in the UI
Decision. Model pending, failed, and success as distinct screens instead of a spinner.
Context. On flaky connections, an ambiguous payment state is worse than a failure.
Consequence. Passengers always know whether they were charged; fewer support calls about duplicate payments.
Seat map bound to live schedule data
Decision. Render the seat map per departure from the booking API rather than a static layout.
Context. Riders wanted their seat, which means live availability for that exact bus and time.
Consequence. The map reflects reality at the moment of booking; seat holds have to be handled by the API.
Every Departure, Compared
Passengers compare real departures — driver ratings, bus photos, exact times, journey length, and price — before picking the one that fits.
40+ Routes Across Georgia
From Tbilisi to Batumi, Zugdidi, and Kutaisi — every route card shows its journey time up front, and the seat map opens one tap later.
Growth & Outcome
Passengers book end to end online — search 40+ routes across Georgia, pick an exact seat, and pay — from any device.
Gallery
