Our role
We engineered HelpMyEvent around the constraint that makes rental different from retail: every listing is a time-bounded resource. Catalogue, checkout and provider tooling were all built to agree on what is free when, in two languages and on local payment rails.
Renting for an event is not retail with a return date. Inventory is a time-bounded resource: a table is available on the Saturday you need it or it is worthless to you, and two bookings for the same weekend must not both succeed. We built availability into the domain model rather than bolting it onto a storefront, so search, product pages and checkout all resolve against the same booking windows and a conflicting reservation fails at the point of intent rather than at the point of payment. The commercial layer was built for the market it serves. Dutch buyers expect iDEAL, which means implementing bank selection and a redirect-and-return journey where the booking must survive the excursion into a banking application and reconcile correctly on the way back. Card payments run alongside it. The platform serves two opposing user classes through role-scoped dashboards, with a guided onboarding that converts an interested supplier into a live listing, and full Dutch and English localisation wired through from the first build rather than retrofitted.
Booking an Event, Not Filling a Basket
Availability Is the Product
Every listing is meaningless outside a date range. Catalogue, detail page and checkout all had to resolve against the same booking windows, and refuse to double-commit a provider for the same weekend.
Dutch Buyers Expect iDEAL
Card-only checkout silently loses Dutch customers. Supporting iDEAL means bank selection and a redirect-and-return flow, where the transaction must reconcile correctly after leaving the application entirely.
Two User Classes, Opposing Goals
Organisers optimise for speed of discovery; providers optimise for control over inventory and calendar. One platform had to serve both without either inheriting the other's interface.
How We Built It
Availability in the Domain Model
Search, filtering and detail pages were built over booking windows from the start, so availability is a property of browsing rather than a disappointment discovered at payment.
A Checkout Built for Local Rails
We implemented iDEAL bank selection and the full redirect-and-return journey alongside standard card processing, with reconciliation that holds when the user returns from a banking app minutes later.
Provider Onboarding and Role-Scoped Dashboards
A guided onboarding converts an interested supplier into a live listing, and separate renter and provider dashboards expose orders, bookings and settings scoped to each role.
Bilingual by Construction
Dutch and English were wired through the interface layer from the first build, so every subsequent feature ships in both languages by default rather than by remembering.
What We Delivered
A Bilingual Storefront
Catalogue, faceted search, product galleries and detail pages, fully localised in Dutch and English.
Date-Based Booking and Checkout
Availability-aware reservation, order management, and payment through iDEAL or card with a reliable return journey.
Dashboards for Both Sides
Provider onboarding, listing and booking management, renter order history, and shared settings and payment methods.
Retention Channels
Direct messaging between organisers and providers, plus newsletter capture for new listings and platform updates.
