Edge Innovation Center

Edge is a workspace and building-management platform built for Raya Smart Buildings, delivered as a mobile application to the people who book space, with a web admin dashboard for the operators who run it. It does not run one building. It runs an estate across more than one country, currently four centres in Egypt and one in Saudi Arabia, with further sites under construction and the footprint extending across the MENA region. It serves individuals reserving space for themselves, corporate users and the administrators who manage their teams and contracts, external visitors, and the centre operators who run the building. Its defining property is that the platform does not stop at the reservation: a confirmed booking is what drives the smart doors, so application state and building state are the same state. Being multi-country is the second property, and it reaches further into the system than a language toggle: currency, timezone, tax and the integrations behind them all vary by where the space physically is.

A reservation system that ends at a confirmed record still needs a person at a desk to unlock a door or issue a badge, which makes that person both the bottleneck and the security gap. A single centre also sells structurally different things (short-term reservations, long-term contracts, corporate arrangements, tours, visitor access), and software shaped around one of them cannot sell the others. Price is not a rate card either: what a space costs depends on the space, the duration, the commercial model, the customer and the contract at the same time. And workspace is bought on physical impression, which a floor plan does not create. Running that across countries adds a dimension the rest of the design has to carry rather than bolt on: a price is meaningless without a currency, a booking window is meaningless without the timezone of the building it opens, and a quote is incomplete without the tax of the jurisdiction the space sits in.

One booking engine carries six commercial models (short-term, long-term contract, corporate, individual, tours and external visits), which converge on a single question, whether a physical space is free in a time window, and differ in everything else. A pricing engine resolves a quote from eight inputs instead of a fixed room rate, and across the estate that quote also has to land in the right currency and carry the right tax for the country the space is in. QNB payment services sit inside the checkout lifecycle under an explicit requirement that payment status and reservation status stay consistent. Every booking window is anchored to the timezone of the building it opens rather than to the person who booked it, and Firebase Cloud Messaging carries push to the mobile app so a booking that starts, changes or ends can say so. Confirmed bookings feed the access-control integration that authorises physical entry through the building's smart doors. A booking is also not only a space. Add-ons attach to it, catering among them, alongside packages and services, and they are fulfilled either by Edge itself or by a third-party vendor. Long-term contracts run on the same engine as the short-term bookings rather than beside it. Around that core sit space search over availability and attributes, corporate management of companies, teams, employees, contracts and access permissions, event registration and attendance, and 3D navigation and 360° views through a 3dNav integration, so a space can be walked before it is booked.

A Flutter mobile app and a Next.js admin dashboard share one backend API. There is no user-facing web application: the people who book space do it on a phone, and the web surface belongs to the operators. As documented, both external systems that matter (the QNB payment gateway and the building's access-control layer) sit behind that API rather than being reached from a client. Inside it, the booking engine is the convergence point: six model-specific lifecycles meet at availability of a physical space in a time window, and pricing resolution runs ahead of checkout so there is a quote to pay against. The gateway result has to flow back into reservation state, because in this system reservation state is what governs physical access. Entry then happens two ways off that one authorisation. A visitor presents a QR, or the booking holder opens the door from inside the app, and both resolve through a WinfiCo IoT integration that drives the physical locks. Two routes to the same door is the sensible shape here, because the two cases are different: a visitor arriving for a tour has no account to act from, and a member already standing at a door they booked should not have to find a code. The estate cuts across all of that. Currency, tax and timezone are properties of the space rather than of the customer, so they resolve from the building being booked and travel with the quote, the invoice and the access window. The stack under all of it is Laravel on Octane over PostgreSQL, with a Flutter mobile app and a Next.js admin dashboard, and Redis carrying the queues so the work that follows a booking, push among it, happens off the request that made it. It runs on AWS, with S3 holding the media and assets and CloudFront delivering them, which keeps asset bytes off the API path entirely. One thing stays unrecorded, and it is a question rather than a missing note: which payment gateway serves the sites outside Egypt, since QNB is the only one documented and the estate now reaches Saudi Arabia.

• A confirmed booking here authorises entry to a building, so a state bug in the booking path is a physical security event rather than a support ticket.
• Timezones stop being a formatting concern the moment a booking opens a door. A window is anchored to the building, not the booker: someone in Cairo reserving a room in Riyadh is buying an hour that exists in Riyadh, and an offset applied in the wrong direction unlocks a door an hour early or leaves someone standing outside one. The usual defence, store everything in UTC and render locally, is necessary here and not sufficient, because the rules that surround the window (opening hours, working days, when a contract renews) are local facts rather than instants.
• Currency and tax attach to the space rather than to the customer, which is what makes them a modelling problem instead of a display one. A price without a currency is not a price, a quote without the jurisdiction’s tax is not payable, and both have to survive the trip from pricing through checkout to invoice unchanged. The pricing engine already resolves from eight inputs; multi-country makes the answer a tuple rather than a number.
• A working week is not a constant across the estate. Egypt and Saudi Arabia do not share a weekend, so availability, opening hours and anything scheduled weekly are per-country facts, and a calendar built on one assumption quietly produces wrong answers in the other country rather than failing loudly.
• Payment and reservation consistency is the familiar distributed-state problem with an unusually sharp edge: a disagreement between the two states does not stop at a billing error; it opens or withholds a door.
• Six structurally different commercial models converge at exactly one point, availability of a physical space in a time window, and diverge everywhere else, including at access control.
• Add-ons turn a reservation into a composite order whose parts are fulfilled by different parties. The space and the door belong to Edge; catering from a vendor does not, and it arrives with its own lead time, its own cancellation window and its own money. One booking therefore holds items the platform controls and items it only coordinates, and any change to that booking has to reach whoever is actually doing the work, not just the record.
• Pricing resolves from eight inputs rather than a lookup, which forces the rules somewhere expressible and orderable and makes a quote something that must still hold between selection and checkout.

• A software state change opens a real door, so correctness of the booking-to-access path is a security property rather than a UX concern.
• Six booking models with structurally different lifecycles sharing one availability layer.
• Eight-input pricing resolution that has to stay expressible, orderable and maintainable.
• Payment and booking state agreeing across a gateway boundary, where disagreement has physical consequences.
• Availability under concurrency: two users, one room, one time slot.
• Heavy 3D and 360° assets against mobile delivery constraints.
• Corporate administrators delegating physical building access to their own staff.
• Multi-country operation: currency, tax, timezone and working week all vary by the country a space sits in, and all of them reach the quote, the invoice and the access window.
• Vendor-fulfilled add-ons: a booking can carry catering and services the platform sells but does not perform, so cancellation, lead time and settlement differ per line item.
• Payment coverage across the estate: QNB is the documented gateway and the estate now extends beyond Egypt.

• QNB: payment gateway inside the checkout lifecycle
• WinfiCo: IoT door access control, driving the physical doors from a confirmed booking
• 3dNav: 3D navigation and 360° views of a space before it is booked
• Firebase Cloud Messaging: push notification delivery to the mobile app

• Laravel
• Laravel Octane
• PostgreSQL
• Redis
• Next.js
• Flutter
• QNB Payment Gateway
• WinfiCo
• 3dNav
• Firebase Cloud Messaging
• AWS
• Amazon S3
• Amazon CloudFront
• Docker