TheEvents
A UAE gifting marketplace of independent sellers, carrying luxury goods and event packages against an occasion calendar, where the buyer is never the person the order is for.
Context
TheEvents is a marketplace for gifts, luxury goods and event packages, founded in the United Arab Emirates and describing itself as one of the region’s leading online marketplaces for events, gifts and lifestyle experiences. Independent sellers hold the stock and run their own storefronts on it, from perfume houses and makeup labels to dealers in European luxury goods at four-figure dirham prices, alongside flowers, cake, chocolate, jewellery, watches, abaya and kaftan. Discovery is organised around occasions rather than product types, across two dozen of them: Ramadan, both Eids, Mawlid and the Hijri new year beside Christmas, Valentine’s Day, National Day, graduations and baby showers. The storefront ships in six languages and delivers across the Gulf, with separate bazaars for Bahrain, Kuwait, Oman, Qatar, Saudi Arabia and the UAE. Four surfaces carry it: a customer web storefront, a customer mobile application, a dashboard the sellers work from, and an administration dashboard behind both.
The problem
Gifting inverts the assumption every commerce system is built on, that the person who browses, pays and receives is one person. Here the buyer is never the recipient, so the delivery address belongs to somebody who has no account, gave no consent and cannot chase a late parcel, and the price has to reach the buyer while never travelling with the gift. Occasion changes what late means as well. A phone charger that slips a day is an inconvenience; a Mother’s Day gift that arrives on the 22nd has failed whatever condition it is in, and it fails through couriers the platform does not control, in the week those couriers are busiest. The calendar is the third difficulty, because half of these occasions are Gregorian and fixed while the other half are Hijri and move roughly eleven days earlier each year, some of them confirmed only days ahead. And none of the stock belongs to the platform: independent sellers hold it, price it, and in the case of event packages supply time rather than goods.
The solution
One marketplace, four surfaces, and a catalogue holding two different kinds of thing. Customers browse a Next.js storefront or a Flutter application, where discovery runs by occasion, category, tag, brand and celebrity curation as much as by search, and where a listing carries variants, ratings and a wishlist. Sellers run their own storefronts from a dashboard, and reach the platform through an onboarding that is a contract rather than a signup: six steps covering the signatory, the company, bank details, a signed agreement and a payment before anything can be listed at all. Administration sits behind both and runs the marketplace itself, covering sellers, occasions, collections, orders and the rules the other two audiences are subject to. Checkout settles by card or by Buy Now Pay Later across four interest-free instalments, and the platform issues stored value of its own as eGift cards, bought for an amount, sent to a recipient by email as a code, and redeemed into a credit balance.
Architecture
A Laravel 10 backend on Octane over MySQL, with Redis in front of the reads that repeat, containerised on AWS. Four clients reach it: Next.js and TypeScript on the web, Flutter and Dart on mobile with Kotlin and Swift underneath it wherever the device has to be reached natively, and two dashboards, one for sellers and one for the platform. Behind the API the catalogue carries products and packages side by side, which are not the same object, and the order side carries a gift rather than a purchase, so buyer, recipient and delivery address are three separate records instead of one customer. Stored value sits beside them, because a gift-card balance is money the platform owes. Three integrations reach outward and fail differently: payment and instalments on the money path, delivery on the deadline, and Firebase carrying push. Redis matters more here than on an evenly traded store, because an occasion marketplace does much of its business in a handful of weeks a year and those weeks move. Not recorded: which gateway, which instalment provider and which couriers sit behind those edges, though the occasion calendar is computed and then corrected by hand, and delivery is run in-house rather than contracted out.
Read this diagram as text
- Customer web
- Next.js and TypeScript. Occasion-led discovery, gift checkout, and the seller application, in six languages across two reading directions.
- Customer app
- Flutter and Dart, over Kotlin and Swift where the work has to be native. The same gifting journey on a phone.
- Vendor dashboard
- Where an independent seller runs their own storefront: listings, packages, stock, pricing and the orders placed against them.
- Admin dashboard
- Where the marketplace itself is run: sellers and their contracts, occasions, collections, orders, and the rules the other audiences are subject to.
- Laravel 10 API
- Running on Octane, containerised on AWS. Single entry point for all four surfaces.
- Products & packages
- Two different objects on one shelf: goods that hold stock and ship, and event packages that reserve a provider’s time on a date.
- Occasions
- The merchandising calendar the storefront is organised around, half of it Gregorian and fixed, half of it Hijri and moving. The moving half is computed from the Islamic calendar and then corrected by hand when the official announcement lands, which is the only honest way to hold a date that is decided by observation rather than arithmetic.
- Gift orders
- Buyer, recipient and delivery address as three separate records, with the occasion date the order has to meet.
- Gift cards & credit
- Stored value: codes issued to an email address, redeemed exactly once into a credit balance the platform owes.
- Redis
- Fronts the reads that repeat, which on a catalogue browsed far more than it is bought from is most of them, and matters most in the few weeks an occasion marketplace actually trades.
- Firebase
- Cloud Messaging, carrying push to the customer application.
- Payment & BNPL
- Card settlement and four interest-free instalments. Which gateway and which instalment provider are not recorded.
- In-house delivery
- Fulfilment against a date that cannot move, run in-house rather than handed to a courier, which is what buys the platform control over the one thing a gift cannot survive losing.
- Customer web → Laravel 10 API (browse, gift, checkout)
- Customer app → Laravel 10 API (gifting on a phone)
- Vendor dashboard → Laravel 10 API (listings, packages, orders)
- Admin dashboard → Laravel 10 API (sellers, occasions, oversight)
- Laravel 10 API → Products & packages (goods and packages)
- Laravel 10 API → Occasions (what is due next)
- Laravel 10 API → Gift orders (buyer, recipient, date)
- Laravel 10 API → Gift cards & credit (issue and redeem)
- Laravel 10 API → Redis (repeated reads)
- Laravel 10 API → Firebase (push delivery)
- Gift orders → Payment & BNPL (settle)
- Gift orders → In-house delivery (deliver on the day)
What makes it interesting
The parts a system like this is actually judged on.
- The buyer is never the recipient, and that one fact rewrites the order. Three things an ordinary purchase treats as one become three: who paid, who receives, and where it goes. The recipient typically has no account, agreed to nothing, and cannot chase a parcel they were never told about, while the price must reach the buyer without ever travelling with the gift. Any component written on the assumption that the account holder is the person at the door inherits the mistake, and it surfaces at the least recoverable moment.
- The trading year runs on two calendars at once. Christmas, Valentine’s Day, National Day and Flag Day sit on fixed Gregorian dates. Ramadan, both Eids, Mawlid and the Hijri new year move about eleven days earlier each year and are confirmed close to the day rather than known well ahead. So the merchandising surface, the stock a seller ought to be holding and the week the couriers will be overwhelmed all shift annually, and the platform’s largest peaks have to be computed rather than looked up.
- A gift dated to an occasion cannot arrive late, only fail. Arrival date is part of what was bought, which puts a hard deadline on a fulfilment chain running through couriers the platform does not control, in precisely the week those couriers are most congested. The person waiting on the outcome never placed the order, so the usual recovery of telling the customer and rescheduling is unavailable: the failure is discovered by the recipient, and reported by nobody.
- Products and packages are different objects behind one cart. A perfume has stock, ships, and can be returned. An event package is a provider’s capacity on a date: it reserves time rather than inventory, cannot be shipped, and fails in a different way when the provider is unavailable. Putting both behind one checkout means the same flow reserves two incompatible kinds of scarce thing and has to honour two incompatible cancellation stories.
- Gift cards are stored value, which is a liability rather than a feature. Selling one takes money now against goods later, issues a code to an email address that may not be an account yet, and credits a balance when it is redeemed. Redeem the same code twice and the platform has given money away, so the interesting half is not the purchase but making redemption exactly once, against a recipient who does not exist in the system until the moment they claim it.
- Six languages, five writing systems and two reading directions, over a catalogue the platform does not write. The interface offers English, Arabic, Hindi, Russian, Chinese and Urdu, but the listings come from independent sellers. Platform chrome can be translated once; every seller’s product title cannot. That splits localisation into a part the platform owns and a part it can only ask for, and the Arabic and Urdu half is a layout problem rather than a string problem, because the page itself has to reverse.
- Luxury on a marketplace is a governance problem rather than a code path. Third parties list European luxury houses at four-figure prices, and no amount of software can inspect a shoe. The six-step seller onboarding is the actual control: a signatory, a company, bank details, a signed agreement and a payment turn an anonymous lister into a known counterparty with something to lose. The buyer still blames the platform, so the defence has to be who was let in rather than what was listed.
Engineering challenges
- A gift order where buyer, recipient and delivery address are three separate things, and the recipient has no account
- An occasion calendar running on Gregorian and Hijri dates at once, so the year’s largest peaks move
- A delivery deadline that cannot slip, through couriers the platform does not control, in their most congested week
- Products and event packages behind one cart, reserving stock in one case and a provider’s date in the other
- Stored value in gift cards, where redeeming one code twice gives money away
- Six languages, five scripts and two reading directions over a catalogue written by independent sellers
- Luxury goods listed by third parties, where the platform is blamed for what it cannot inspect
Integrations
- Payment gateways: card settlement at checkout; which gateways is not recorded
- Buy Now Pay Later: four interest-free instalments at checkout; the provider is not recorded
- In-house delivery: fulfilment against an occasion date is run by the platform rather than contracted out
- Firebase: push notification delivery to the customer application
Technology
- Laravel 10
- Laravel Octane
- MySQL
- Redis
- Next.js
- TypeScript
- Flutter
- Dart
- Kotlin
- Swift
- Firebase
- AWS
- Docker