Travel technology · multi-vendor marketplace
Wenjoy lets travellers find and book private farmhouses, villas and holiday homes across the seven Emirates, while hosts, agents and the platform team work from their own dashboards. The hard part was never the property gallery; it was making availability, pricing and payment states agree for everyone at once.
Custom web application developmentProject overview
Wenjoy is a marketplace for private stays in the United Arab Emirates. A traveller lands on the homepage, picks an emirate, a date range and a guest count, and browses farmhouses, villas and holiday homes with nightly prices in dirhams and guest reviews on every card. Behind that public surface sit three more audiences: hosts who list and manage properties, agents who bring bookings through their own channel, and the platform team who approve listings, handle support and keep the transaction record straight.
The product exists because independent UAE operators were listing on international travel sites that charge high commissions and understand little about a farm stay in Al Ain or a family villa in Ras Al Khaimah. Wenjoy gives those operators a direct channel with local payment methods, Arabic and English support and a catalogue organised the way people actually plan a weekend: by place, by dates, by who is coming.
Technically it is a Laravel application with MySQL behind it and Bootstrap on the front, which is a deliberately conventional choice. The interesting engineering is in the domain model: how availability, price rules, reservations, payment holds and refunds stay consistent when four different kinds of user can change them.
The original challenge
A booking site is not a gallery with a date picker. Once independent hosts, fluctuating nightly rates, deposits and third-party calendars enter the picture, the small details become the product.
A night that a host blocks by hand is not the same as a night taken by a confirmed reservation, and neither is the same as a block imported from another platform. If all three write to one availability table without saying where they came from, removing a manual block can silently reopen a booked night.
A vendor manages their own listings and calendar. An agent needs controlled access to make bookings on behalf of clients. Administrators oversee approvals, support, transactions and trust. Getting this wrong is a backend permission problem long before it is a dashboard design problem.
Holds, confirmations, cancellations and refunds each change what the guest sees and what the host is owed. A guest-facing action must be traceable back to an operator-side record, or support conversations turn into archaeology.
Property imagery, nightly pricing, guest controls and emirate navigation have to be scannable on a small screen, in Arabic and English, without the search losing the dates the visitor already chose.
Engineering decisions & solutions
The decisions below are the ones that shaped the codebase. Each records the trade-off we accepted and what still needs work.
Manual blocks, confirmed reservations and imported calendar entries all compete for the same nights.
Without provenance, a host clearing a manual block could reopen a night that a guest has already paid for; the reverse can hide genuinely free nights and cost bookings.
Treat owner-managed blocked dates as their own explicit records and write them through to listing availability, with separate paths for integration imports and true reservations.
Blocked dates are stored with their origin and written through to the availability the search reads. Reservations change availability only through the booking workflow. A calendar-app single-device takeover and PIN access were introduced so two sessions cannot edit the same host calendar against each other.
Keeping the origin of every block adds a layer of bookkeeping and more cases to test; a single flat table would have been simpler to build and far harder to trust.
Manual blocks and reservations no longer overwrite each other. Third-party channel sync is still being verified connection by connection and is not described here as complete.
Guests want a fast, visual search; hosts and agents want management screens; both must reflect the same listings instantly.
A new listing that takes hours to appear in search, or a dashboard that shows different availability from the public page, destroys trust on both sides.
Keep one catalogue and one availability model, and build the guest site and the operator dashboards as separate interfaces over it.
The public site groups farmhouses and holiday-home types, filters by emirate, stay dates and guest count, and renders property cards with price and review counts. Host onboarding, property management and agent access are separate authenticated areas reading the same records.
Two interfaces mean two sets of screens to maintain; the alternative of a single generic admin would have been cheaper and much worse for guests.
Listings appear in search as soon as they are approved, and operators see the same availability the public sees.
UAE guests expect card payments, wallet payments and buy-now-pay-later options; international platforms rarely offer the last.
Checkout friction is where marketplace bookings die, and a share of the local audience will not complete a card form on a phone.
Integrate a payment stack that covers cards, Apple Pay, Google Pay and the regional instalment providers Tabby and Tamara, and model each provider's hold, capture and refund behaviour explicitly.
The live checkout displays Visa, Mastercard, Apple Pay, Google Pay, Tabby and Tamara. Payment states (hold, confirmed, cancelled, refunded) are recorded against the booking so the guest view and the operator view agree.
Each provider has different authorisation and refund semantics, which multiplies the test matrix; a cards-only checkout would have been simpler and would have excluded instalment buyers.
Local payment choice is live. Regression testing of authorisation and refund scenarios across providers remains an ongoing engineering task.
Travellers plan by place and date, not by an internal property taxonomy.
A catalogue organised around database categories forces visitors to translate their plans into the site's vocabulary instead of the other way round.
Build navigation and landing pages around emirates and property types, keep dates and guest counts sticky through the journey, and support Arabic and English visitors.
The homepage and footer expose emirate pages (Dubai, Abu Dhabi, Sharjah, Ajman, Ras Al Khaimah, Fujairah, Umm Al Quwain, Hatta, Al Ain, Dibba) and property-type collections; support is offered around the clock in Arabic and English.
Place-based landing pages need real inventory in each place to be worth indexing; thin emirates are kept as navigation rather than promoted as destinations.
Visitors can move from a city to a dated, priced list of stays in two clicks on mobile.
Main features
Everything listed here is visible on the public site or documented in the project; nothing is a roadmap item dressed up as a feature.
Technical architecture
The stack is conventional on purpose. Laravel gives us routing, authentication, queues and a mature ORM; MySQL holds listings, availability, bookings and payment states; Bootstrap keeps the responsive layout predictable across hundreds of screens.
The parts that carry the risk are the domain rules: how a blocked night is represented, which role may change what, and how a payment event moves a booking between states. Those live in application code and are covered by scenario tests rather than left to the interface.
What we deliberately leave out: credentials, hosting topology, internal endpoints, provider keys and fraud rules are intentionally not described.
| Layer | What is in place |
|---|---|
| Backend | Laravel (PHP 8.2) application with role-based authorisation for guests, hosts, agents and administrators |
| Data | MySQL: listings, media, availability with provenance, reservations, payment states, reviews |
| Frontend | Server-rendered Blade views with Bootstrap 5, responsive from 360 px upwards, Arabic and English |
| Payments | Card, wallet and instalment providers (Visa, Mastercard, Apple Pay, Google Pay, Tabby, Tamara) mapped to explicit booking states |
| Availability | Owner blocks, reservations and imported entries stored separately and written through to the searchable calendar |
| Calendar sessions | Single-device takeover and PIN access for host calendar editing |
| Discovery | Emirate and property-type landing pages, date and guest filters, review counts on cards |
| Operations | Listing approvals, support tooling and transaction review in an administrator area |
User experience & responsive design
Genuine screenshots of the public site captured on 23 October 2026. Hover and click any image to open it in the viewer; click again for actual size.
The first screen asks the three things a traveller already knows: where, when and how many. Everything else, from property types to emirate pages, is a shortcut into that same search.
Nightly price in AED, review count and the key facts appear before a visitor opens a property, so the shortlist is built from comparable cards rather than from hero images.
On a phone the imagery leads, the price stays visible, and the booking controls sit where a thumb reaches. Emirate chips replace deep menus.
Hosts and agents get task-oriented dashboards instead of a cut-down version of the public site; the vocabulary is theirs (listings, calendar, payouts), not the guest's.
Arabic and English support is part of the product, with support offered in both languages, not a translation layer bolted on afterwards.
Headings follow the page outline, controls are real buttons and links, and the forms behave on keyboard. Colour contrast on price and review text is kept high against photography.
Technical challenges & resolutions
Each row records how it was verified and what remains open. Items marked as recommendations have not been implemented yet.
| Challenge | Root cause / constraint | Solution | Verification | Result or remaining limitation |
|---|---|---|---|---|
| Cleared manual blocks could reopen booked nights | One availability table with no record of why a night was unavailable | Store blocks with their origin; write reservations through the booking workflow only | Scenario tests on block, book, unblock sequences; manual review of host calendars | Fixed in the application; third-party channel sync still being verified per connection |
| Two sessions editing one host calendar | Host accounts shared across devices and staff | Single-device takeover and PIN access for calendar editing | Exercised during host onboarding support | In place; usability feedback from hosts is still being gathered |
| Payment state visible to the guest did not always match the operator record | Provider callbacks arriving out of order | Explicit booking states driven by provider events, with the operator record as the source for the guest view | Sandbox runs per provider; production monitoring of state transitions | Improved; full regression coverage of authorisation and refund paths across all providers is an open item |
| Agents needed access without host powers | A single 'operator' role had been assumed early on | Separate agent role with server-side permission checks | Role-based tests; manual checks of agent screens | Delivered; the agent registration flow is being reviewed as part of ongoing QA |
| Search felt slow on image-heavy result pages | Large property images loaded eagerly | Lazy loading below the fold and sized image slots | Browser profiling on mobile throttling | Improved; formal Core Web Vitals documentation is still to be published (recommendation) |
Estimated market development cost
If a UAE business commissioned a marketplace with this scope today, these are the ranges we would expect from a competent agency. They are editorial estimates for comparable work, starting from the project's documented scope and checked against public 2026 pricing guides.
Comparable scope, 2026 market range
AED 120,000 – 350,000
Roughly 700–1,400 hours of design, engineering, QA, documentation and deployment at a blended agency rate; scope-dependent.
The range covers the live scope: public discovery, host, agent and admin areas, the availability model and the payment stack. Ongoing channel-sync work and marketing are additional.
Illustrative market development estimate for a comparable scope. This is not the actual project invoice, historical development cost or amount charged to a client.
| Comparable delivery component | Estimated range (AED) |
|---|---|
| Product discovery, flows and interface design | 10,000 – 25,000 |
| Property listings, discovery and guest checkout | 20,000 – 65,000 |
| Host, agent and administration dashboards | 25,000 – 85,000 |
| Booking calendar and integration work | 30,000 – 90,000 |
| Payment flows, policies and lifecycle states | 15,000 – 45,000 |
| QA, deployment and production hardening | 20,000 – 40,000 |
Component ranges are illustrative phase allocations, not measured hours or invoices. Third-party subscriptions, paid APIs, content production, hosting and marketing are excluded. Market context: Clutch web development pricing guide (Sept 2026), Dubai website cost comparison (Sept 2026) — editorial estimates by WebStackRank, not independently obtained quotes.
Results & outcomes
Wenjoy is a working marketplace, and the outcomes below are the ones a visitor can confirm on the site today. We publish no booking volumes, revenue or conversion rates for it because none have been independently verified for publication.
Search by emirate, dates and guests; property pages with AED pricing and reviews; emirate and property-type landing pages across the seven Emirates.
Host registration and management, agent registration and sign-in, and an administrator area for approvals, support and transaction review.
Cards, Apple Pay, Google Pay, Tabby and Tamara at checkout, with payment states recorded against each booking.
Blocked dates carry their origin, reservations flow through one workflow, and host calendars are protected from conflicting sessions.
A responsive interface with Arabic and English support that holds the visitor's dates and guest count through the journey.
Support staff can follow a guest-facing action back to the operator record that caused it.
What this page does not claim: the homepage counters, listing totals, revenue, conversion rates and the completeness of third-party calendar connections. Those figures are not published here until they have been verified from production records.
Lessons learned
Project status
Live · ongoing development
wenjoy.ae is a working public marketplace: visitors can search by emirate, dates and guests, open property pages with nightly prices in AED and reviews, and reach host, vendor and agent entry points. Development continues on calendar integrations and payment-lifecycle hardening.
Status and figures reviewed on 23 October 2026 against the public site. Wenjoy is an in-house product: it is owned and operated by the WebStackRank founder, not commissioned by an outside client.
Related projects
Whether you're planning a booking platform, SaaS product, business website or custom application, WebStackRank can help you turn the idea into a practical, maintainable digital product.
How would you like to reach us?
Thanks for chatting!
It was lovely to connect. Come back anytime — our starter packages and their 3 months free maintenance are on the pricing page whenever you're ready. See you again!
See the pricing page
