The homepage is the recognition. This page is the spec sheet for the buyer who needs to see the machine before they commit.
What you own.
Owning your stack is not a slogan. It is the sum of concrete moving parts: surfaces, modules, integrations, pipelines, the reliability posture behind them, and a fit filter that tells you honestly whether this is for you. Everything below is real; it comes from a delivered platform.
Every platform we deliver runs on engines, not modules. An engine owns a domain end to end. It fails in isolation, recovers in isolation, and is replaceable without rewriting the whole.
Twenty-one engines. Eight layers. One platform.
Below is the actual architecture of a delivered platform. Twenty-one engines spanning eight infrastructure layers, serving four actor surfaces. Nothing is theoretical. Every engine listed here ships under load, today, on live reservations and live payments.
Authentication Engine
JWT issue + refresh, email + phone OTP, OAuth bridges for Google · Facebook · Apple. Tenant, owner, and admin identities, separate trust levels.
Admin Engine
OTP-gated admin console with tiered role authorization. Runs the platform without a developer in the loop.
Owner Engine
Guesty OAuth-bridged owner dashboard. Revenue, calendar, statements, portfolio performance.
External Sync Engine
Webhook ingress + outbound API calls to the upstream PMS. Rate limiter, circuit breaker, token-refresh backoff, signature verification.
Data Mirror Engine
Local replica of upstream inventory. Guests always read in-tenant. The platform stays live even when the PMS stutters.
Availability / Calendar Engine
Per-night state, overrides, minimum-nights, webhook-synced. One row per listing-day, compound-unique.
Pricing Engine
Listing markups, account-level fallback, platform + service fees, five-minute quote cache with explicit invalidation on calendar updates.
Search Engine
Sub-second database-backed search. Date-aware card prices, per-night breakdown, and priceSource provenance stamped on every result.
Web Booking App
React 19 + Vite, server-side rendered, nginx-fronted. Dashboard-managed content, analytics-wired, SEO prebuild.
Mobile Booking App
Flutter iOS + Android. Thirty-eight screens, fifty routed destinations, native Stripe sheet, push notifications, offline-resilient browsing.
Direct Booking Engine
OTA-bypassing flow. Every booking closed here keeps the full margin in the operator’s pocket, not an intermediary.
Payment Engine
Stripe PaymentIntents with 3-D Secure and CCAvenue form-submit for regional markets. Saved cards, webhook-verified transactions, mobile native payment sheet.
Payment Recovery Engine
BullMQ-backed reconciliation for failed or mid-flight payments. No ghost reservations, no lost revenue in the gap between intent and confirmation.
Mobile Recovery / State Engine
Schema-versioned checkout state persisted for twelve hours. Resumes in-flight confirmations after an app kill or network drop.
Reservation Engine
Booking lifecycle from confirmation through check-out. Publishes events that other engines subscribe to.
Notification Engine
Email + SMS + push via SendGrid, Twilio, FCM. Retry-safe through BullMQ, templated for brand consistency.
Queue Engine
Three BullMQ queues on Azure Redis: payment recovery, notifications, PMS ops. Producers and processors kept separate by design.
Config / Rules Engine
Live feature flags, pricing fees, account markups. Five-minute cache, invalidated explicitly, observable in admin.
Content / CMS Engine
Blog, FAQ, help center, hero sliders, legal pages. Fully admin-managed. Zero developer involvement for copy changes.
File / Document Engine
Azure Blob uploads for photos and attachments. Per-booking PDF confirmations generated on demand.
Analytics / Conversion Engine
Google Tag Manager, GA4, Facebook Pixel, Microsoft Clarity. Conversion events wired to every booking-completed path.
Cloud Hosting Runtime
Azure App Service pulling containers from the tenant registry.
Version Control & CI/CD
GitHub Actions → ACR → App Service. Eight pipelines, zero-downtime deploys.
Document Database Layer
Two MongoDB Atlas clusters. PMS mirror + platform core, kept separate by concern.
Cache & Queue Layer
Azure Redis fronting BullMQ queues, autocomplete cache, and quote cache.
File Storage Layer
Azure Blob Storage for every guest photo, owner document, support attachment.
Payment Processing Layer
Stripe as primary, CCAvenue for regional coverage. Both webhook-verified.
Messaging Delivery Layer
SendGrid, Twilio, FCM, and a Microsoft Teams error sink for operations.
Analytics & Attribution Layer
GTM-fronted GA4, Facebook Pixel, and Microsoft Clarity for session replay.
This is what ownership looks like, once you can see the shape of it.
Reference architecture · representative delivered platform · April 2026 · details under NDA
Enterprise-grade is a posture, not a badge. Below are the targets we commit to, the postures we hold, and the conduct that follows. If we miss a target, we say so in writing.
Operator-grade, not checkbox-grade.
No certifications we haven't earned. No SOC2 badge we don't hold. The targets below are what we commit to on every platform we deliver, and the conduct that matches them on the day of any real incident.
- 01Encrypted credentials, bcrypt, never recoverable in reverse
- 02Token-based sessions, short-lived, secure refresh flow
- 03Webhook cryptographic verification on every inbound event
- 04Input validation and sanitization, framework-level, at every endpoint
- 05CORS and origin enforcement, authorized domains only
- 06HTTPS and TLS 1.2+ on every surface, every request
- 07Error escalation, captured and routed to operations in real time
- 08Audit logging for booking, payment, admin actions, fully traceable
“Security is not a feature we check off once. It is an ongoing discipline: layers added, assumptions tested, exposure reduced continuously as the platform matures from production-ready to enterprise-grade.”
Two lists. Honest about the fit. If you see yourself on the left, we will build something serious together. If you see yourself on the right, another vendor will serve you better.
Is this for you?
No radar charts. No psychographic profile. Just the sort of operator this platform is built for, and the sort it is not.
- 01Operators tired of renting growth through third-party platforms
- 02Businesses ready to own their stack, not just patch tools together
- 03Teams with real operational complexity and revenue at stake
- 04Founders who value infrastructure, speed, and execution over appearances
- 05Companies prepared to invest in systems that compound
- 01People looking for a cheap website and a few ads
- 02Teams that want dashboards without operational change
- 03Businesses that do not want to own their data, flow, or infrastructure
- 04Buyers chasing the lowest bid instead of the strongest system
- 05Operators who want cosmetic growth instead of structural advantage