EKYON CASE STUDY / HOTEL BIDDING PLATFORM

BidMyRoom.
A hotel bidding
platform, designed
and built.

An organizer shares the stay they need. Hotels respond with offers tailored to its dates, room count, and budget.

Our delivery Product design, a public website, traveler and hotel applications, administration, and shared backend integrations.

BidMyRoom traveler and hotel interface excerpts, with Ekyon's website, application, and backend delivery scope
Source frontend components with synthetic demo data.
SERVICES PROVIDED
Product design & full-stack development
DELIVERY SCOPE
Website, web apps, mobile apps & backend
DEVELOPMENT PERIOD
2025–2026

01 / WHAT EKYON PROVIDED

What we delivered
for BidMyRoom.

We designed and developed the experiences for travelers and hotels, then built the applications and services that support them. The project included six distinct parts of the product.

The sections below show the delivered interfaces and implementation scope. Mobile and administration are documented from source.

02 / UNDERSTANDING THE PRODUCT

A stay request becomes
the starting point.

BidMyRoom brings a request-led approach to hotel booking. A wedding organizer, team coordinator, or company arranging a crew stay can share requirements once and receive hotel proposals. Hotels can respond to that specific demand with a tailored rate and a conversation.

THE CLIENT’S PRODUCT MODEL

  1. 01

    Describe the stay

    Destination, dates, rooms, budget, and requirements.

  2. 02

    Receive hotel proposals

    Hotels review the request and make an offer.

  3. 03

    Compare and discuss

    The organizer evaluates offers and talks with hotels.

HOW WE TRANSLATED THAT INTO SOFTWARE

Structured request forms capture the details hotels need. Separate workspaces support the organizer and the hotel team. Shared services connect every offer and conversation back to the stay.

Request types and the two booking paths

The implementation supports individual, group, and corporate requests. Group requests carry a group name and type; corporate requests can include company and project details. Direct hotel bidding and Expedia inventory checkout are separate paths. Accepting a hotel offer does not automatically create an Expedia reservation.

03 / DELIVERY / WEBSITE & TRAVELER APPLICATION

The public presence.
The customer product.

We provided the public website and the traveler web application behind it. The scope connects use-case pages and hotel discovery with request creation, offer comparison, conversations, and a separate provider booking journey.

PUBLIC WEBSITE

A starting point for
different kinds of stays.

Use-case pages
Group booking, weddings, sports teams, corporate travel, crew housing, and events.
Discovery & product entry
Destination, date, and traveler inputs, hotel listings, property pages, and request creation.

BidMyRoom / Public website

The delivered BidMyRoom public website, with stay criteria and hotel discovery entry
Public website shown in the supplied screenshot.

TRAVELER WEB APPLICATION

From a request to an informed decision.

We designed the offer view to keep the nightly rate, property context, and stay requirements together, with the conversation close to the proposal.

BidMyRoom / Source frontend components

Delivered traveler offer components showing rates, property details, stay requirements, and conversation actions with synthetic data
Actual traveler frontend components, rendered locally with synthetic data while the backend is offline.
Request & offer interfaces
Forms for different stay types, account and request views, hotel offers, and conversation panels.
Provider booking interfaces
Room selection, guest details, price breakdowns, payment, review, and confirmation pages.
Traveler application implementation

The traveler application uses Next.js and React. Shared request data populates its offer cards and conversations. Provider booking screens account for room occupancy, inclusive and exclusive pricing, and charges due at the property. A frontend integration guide documents the occupancy and fee-display implementation. Screenshots use synthetic API fixtures and do not demonstrate completed reservations.

04 / DELIVERY / HOTEL WEB APPLICATION

A working environment
for the hotel team.

We provided a separate hotel application for receiving demand and responding to it. Its scope includes property setup, a lead workspace, offer creation, conversations, staff permissions, and subscription management.

BidMyRoom / Source frontend components

Delivered hotel lead components showing stay requests, dates, room counts, and hotel response actions with synthetic data
Actual hotel lead components with synthetic data. The surrounding page is a local capture harness.
Property onboarding & profile
Hotel selection and setup, details, photos, amenities, and policies.
Lead & bidding workspace
Stay requirements, lead actions, offer forms, and hotel conversations.
Team access
Staff accounts, roles, and permission controls for hotel-side work.
Account & subscriptions
Profile and password settings, subscription views, and billing integration.
Connecting the hotel interface to business rules

A hotel lead links the property and staff account to a stay request. The offer form calculates the quoted total using nightly rate, room count, and duration, and sends a typed offer into the related conversation. Staff messages retain the account identity while belonging to the hotel's shared conversation.

05 / DELIVERY / MOBILE & ADMINISTRATION

Mobile access for both sides.
Tools for the operator.

The delivery included two mobile application codebases and a dedicated administration web application. Travelers and hotel teams have their own mobile experiences; the business has a separate place to oversee accounts, properties, and requests.

MOBILE APPLICATION

Traveler app

Stay requests, hotel browsing, offers, conversations, account screens, and provider booking screens.

React Native / Expo
MOBILE APPLICATION

Hotel app

Property onboarding, leads, bidding conversations, hotel details, staff access, and subscriptions.

React Native / Expo
WEB APPLICATION

Administration

User, hotel, and hotel-staff management, request details, broadcasts, and access controls.

Next.js / React

Connected through shared backend services

Accounts · Requests · Leads · Conversations

Mobile and admin scope verified in the source code. The visuals here document application scope; they are not device or admin screenshots.

Application boundaries

The project contains separate traveler, hotel, and administration Next.js applications, plus separate traveler and hotel React Native / Expo applications. Shared backend services provide the business records and integrations. Mobile apps were inspected without launching iOS or Android simulators. This case study makes no claim about current app-store availability.

06 / DELIVERY / BACKEND ENGINEERING

The rules and services
behind the interfaces.

We implemented the backend that turns a stay request into hotel leads, connects offers to conversations, and updates related records when a decision is made. Messaging and notifications connect that work across the applications.

Request & lead services
Structured stay records, nearby-hotel lead creation, request status, and expiry rules.
Offer & conversation services
Typed offers, message delivery, acceptance and decline actions, and defined conversation windows.

BidMyRoom / Source frontend components

Delivered traveler conversation interface showing a synthetic hotel proposal, messages, and offer decisions
Actual conversation components with synthetic messages and offer data. Actions were not submitted to a live backend.

ONE EXAMPLE OF THE ENGINEERING SCOPE

An accepted offer updates
the related work.

  1. The request, chosen lead, and conversation become accepted.
  2. Competing bid leads are declined and their conversations close.
  3. New unbid leads are removed; hotel staff receive updates.
Acceptance and follow-up rules

The acceptance service saves accepted states for the request and selected conversation, declines competing bid leads, marks the selected lead accepted, removes new unbid leads, and closes other conversations. The chosen conversation has a seven-day follow-up window. This describes implementation found in source, not a backend transition exercised during capture.

07 / DELIVERY / EXTERNAL INTEGRATIONS

Booking, billing, and updates.
Connected to the product.

Our integration work covered the services around the core bidding experience: provider reservations, hotel subscriptions, live messages, email and mobile notifications, and property media storage.

ReservationsExpedia Rapid
Property discovery, availability, price checks, booking records, recovery, and cancellation handling.
Hotel billingStripe
Hotel subscription creation and changes, billing portal access, and subscription status synchronization.
Messages & notificationsSockets, email & Expo Push
Message updates and notifications for requests, offers, hotel staff, and booking events.
Property mediaAWS S3
Upload and storage services for hotel photos and other media.
The implementation around a provider reservation

The Expedia path includes current-price checking before booking, itinerary and confirmation records, payment-session handling, recovery, and cancellation endpoints. Webhooks and itinerary refresh update later booking states. Hotel subscription billing uses Stripe separately. Integration scope was verified in source; no live payments or production bookings were exercised.

08 / THE PROJECT AS A WHOLE

Design and development
across the full product.

BidMyRoom shows the scope we can take on when a product needs more than a public website: distinct user applications, operational tools, custom business logic, and external services that work around the same product model.

DELIVERED IMPLEMENTATION

  • Public website and traveler web application
  • Hotel and administration web applications
  • Traveler and hotel mobile codebases
  • Shared backend and external integrations
  • Frontend integration documentation
Technology and implementation documentation

Web: Next.js, React, and TypeScript. Mobile: React Native and Expo. Shared services: Express, TypeScript, and MongoDB. The traveler repository includes a frontend integration guide for guest occupancy, price breakdowns, taxes and fees, and charges due at the property.

YOUR PROJECT WITH EKYON

What does your product
need us to deliver?

We can help define the design, applications, and integrations your business needs.

Discuss your project
← Explore more projects