Case Study · 2025

Rojaboom

An online platform for booking quality and luxury stays in Iran

Frontend Developer · Zero to launched product

02 — From Zero to Launch

Version 1 in under two months.

The project started under a hard deadline: get a launch-ready, solid Version 1 out in less than two months.

Figma designs arrived in parallel with development. Build and design moved together — decisions did not sit on a finished canvas, and the frontend had to absorb real change while shipping.

From scratch to a launchable product
Design and development in parallel
A standard-quality Version 1 under time pressure
Speed without hollowing out the foundation

03 — One Platform, Three Roles

Guest, Host, and Admin — three angles on one product.

Rojaboom was never just a booking page. Three primary roles defined the real product scope.

I owned the Guest and Host frontend. The Admin panel was later built in Laravel because of severe time constraints.

Guest

Search, accommodation detail, date selection, and the booking path.

An experience that had to feel simple — even when calendar, pricing, and availability sat underneath.

Host

Listing creation, bookings, calendar, property data, and financial operations.

Where product depth shows up: an operational dashboard for real hosts.

Admin

The platform’s internal management layer for operations and support.

Built later in Laravel under intense time pressure.

04 — The Host Experience

Behind a simple experience sat a full system.

Hosts were not only “adding a listing.” They managed bookings, calendar, property data, and money in one connected flow.

The Host dashboard had to be clear and operational at once: multi-step flows, dynamic tables, simple and complex forms, and interactions that matched day-to-day host work.

Host dashboard
Booking management
Calendar management
Property details
Financial operations
Multi-step flows

05 — Twelve Steps to List a Property

A complex business flow — not just a long form.

Host listing creation was a twelve-step, dependent process that had to be completed in a defined order.

During development, stage structure, required fields, validation rules, step dependencies, and even information order were redesigned repeatedly. The real work was keeping the flow coherent while the product was still defining itself.

Twelve dependent steps

01
Step dependencies
Each stage leaned on data and decisions from the previous one. The flow could not be treated as isolated screens.
02
Shifting requirements
Stage structure and required information changed several times. The system had to stay rearrangeable, not brittle.
03
Living validation
Validation rules moved with the product. Errors had to stay clear without breaking the user’s path.
04
Reordering information
UX and field priority were reshuffled more than once. Flow architecture had to absorb that motion.

06 — A Calendar Built from Scratch

The calendar was one of the product’s technical pillars.

Rojaboom’s calendar was built from scratch — not as a decorative widget, but as a core interaction surface for booking and availability.

UX and engineering met here: range selection, daily pricing, blocked days, display modes, and state management across real interactions.

01
Range selection
Range mode for the booking path, with predictable start, end, and edit behavior.
02
Per-day pricing
Daily prices shown inside the calendar itself — not separated from the user’s decision.
03
Host-blocked days
Blocked or occupied days had to be readable and reliable in the moment.
04
Single and Double modes
Two display modes for different date selection and browsing scenarios.
05
Modal and full-page
The same calendar opened in a modal and rendered fully on the accommodation page.
06
Holidays and complex state
Holiday display alongside the interaction and state behaviors a real booking platform needs.

07 — Forty-Three Screens Behind the Experience

Real product breadth — not a few showcase pages.

The final version had about 43 screens. The number matters less than the kind of work they covered.

Those screens combined guest booking workflows, host operational interfaces, light and heavy forms, dynamic tables, map-based location selection, and multi-step flows.

Guest booking
From discovering a stay to choosing dates and completing a reservation.
Listing creation and management
Flows for creating, editing, and maintaining property data as a host.
Day-to-day host operations
Bookings, calendar, dashboard, and routine host decisions.
Forms and tables
From simple forms to complex ones, plus dynamic tables.
Multi-step flows
Processes that had to advance stage by stage while preserving state.
Map-based location
Map interactions for setting accommodation location.

08 — Shipping Under Constraints

Shipping when infrastructure was not on your side.

Part of development and deployment happened under severe internet and infrastructure constraints — international outages, package-registry limits, and datacenter issues.

This is not a dramatic story. It is an example of problem-solving when the usual tools are unavailable and the product still has to go out.

01
Access cuts
International internet outages and registry limits blocked the usual install and release path.
02
Infrastructure instability
Datacenter issues and unstable conditions pulled debugging and deployment out of routine mode.
03
An alternate release path
In one hard deployment, the project shipped with Liara CLI using domestic registry mirrors as package-install substitutes.

The takeaway was clear: engineering quality is not only measured in ideal conditions — it is also measured by getting the product out when constraints are real.

09 — More Than a Launch

The product did not end at launch.

Version 1 was only the starting point. Rojaboom ran for more than a year in a real environment and against real platform traffic.

Through that period, new features, bug fixes, requirement changes, and operational needs continued on the same foundation.

01
Tight launch
Getting Version 1 to a usable product in under two months.
02
Real usage
More than a year with real users, bookings, and operations on the platform.
03
Iteration and upkeep
Features, fixes, shifting needs, and day-to-day operational pressure.

10 — When the Stack Changed

Migration was an organizational decision — not a technical verdict.

More than a year later, the whole project moved to Laravel.

This matters: the move should not be read as a failure of Next.js. The Next.js version was technically sound and worked correctly in production.

The migration decision was driven more by organizational and operational reasons than by technical inability of the previous stack.

What shaped the decision

Faster support needs
The business needed continuous change and operational response.
Frontend–backend alignment
New features required closer coordination between both sides.
Team structure
Three Laravel developers were on the team; frontend expertise stood alone.
Lower operational risk
Support and development became simpler for a team already centered on Laravel.

Technology choice is never only about technical capability — it also has to align with team structure, operations, and business needs.

11 — What I Owned

The real scope of responsibility.

From frontend architecture to deployment — these are the parts I actually carried on the project.

01Frontend architecture
02Guest experience
03Host dashboard
04Booking flows
05Listing creation flow
06Custom calendar
07Forms and validation
08Dynamic tables
09Map interactions
10API connection
11Responsive UI
12Bug fixing
13Deployment

Rojaboom was never only a fast launch.

It was practice in shipping a real product under time pressure, constant change, and operational constraints.