CONFIDENTIAL PROJECT · PROPERTY & HOSPITALITY

Property Management & Booking Platform — Real Estate, Hospitality & Multi-Property Operations

A full-stack property platform combining online booking, property and room management, reservations, customer CRM, billing, multilingual content and location-aware property data.

Originally developed for a regional tourism operator; the architecture can extend into property-management, vacation-rental, serviced-apartment, hospitality and real-estate platforms. Client name omitted.

CodeIgniterPostgreSQLPostGISBooking enginePMSMultilingual
Build a Property Platform See screenshots AI path
Industry
Hospitality · tourism · property ops (adaptable)
Type
Public booking portal + PMS back office
Catalogue
96 properties · 462 rooms · 296 CMS pages · 1,774 strings
Stack
CodeIgniter 2.1 · PostgreSQL + PostGIS · Metronic
Proof
16 working screens · dual portal
PROPERTY · HOSPITALITY · BOOKING

Property → room/unit → availability → reservation → customer → invoice → CMS.

Who this is for. Teams building property management, vacation-rental, hotel booking or multi-property real-estate platforms—not only tourism microsites.

What you get. Evidence of a dual-portal CodeIgniter + PostgreSQL/PostGIS system: public booking, reservation board, invoicing, entity CRM, multilingual CMS and location-aware property data. Regional tourism was the original vertical—not the limit of the architecture.

Searches this page answers: property management software development · PMS · vacation rental booking · multi-property platform · real estate software · hospitality booking · PostGIS property search · custom PMS modernization

Who this platform is for

Hospitality & short-stay

Hotels, resorts, villas, serviced apartments, vacation rentals, regional tourism operators.

Real estate & multi-property

Portfolio managers, residential/commercial operators, co-living and builders (via modernization path).

Direct-booking owners

Branded search & book without depending only on OTAs.

Legacy PMS modernizers

Keep the domain model; replace insecure stacks with API-first services + AI later.

The property-operations problem

Travellers needed type, destination, dates and party size—then filters (price, stars, services, board) and a property dossier with real room availability. Operators needed structures, room types, seasonal prices, packages, reservations, customers, invoices and three languages without the public site and spreadsheets diverging.

Distributed guests + multi-property inventory + direct booking + back-office ops is the actual opportunity—not “another tourism brochure.”

Constraints

Delivery stayed inside the client’s stack and media-ownership boundaries. Client name omitted; screenshots are from a private install / local dataset. AI Voice, channel manager, long-term lease/maintenance and IoT below are labeled future extensions, not shipped features of this build.

Two markets, one property core

Hospitality / short-term

  • Hotels · resorts · villas
  • Serviced apartments
  • Vacation rentals · tourism portals

Real estate / property ops

  • Residential & commercial portfolios
  • Property managers · co-living
  • Builders · multi-property owners

Shipped primitives: property → unit/room → availability → reservation → customer → invoice → payment → CMS/reviews. That is reusable for hospitality today and real-estate modernization tomorrow.

Modern property platform (components)

PROPERTY PLATFORM
                           │
        ┌──────────┬───────┼────────┬──────────┐
        ▼          ▼       ▼        ▼          ▼
      PMS       Booking   CRM    Payments   CMS
        │        Engine    │        │          │
        └──────────┬───────┴────────┴──────────┘
                   ▼
              Automation / AI (future)

Vacation-rental and hospitality buyers increasingly expect PMS, booking engine, channel manager, CRM, payments and automation as a connected stack—not one isolated form. This case study proves the PMS + booking + CRM + billing + CMS core.

What was delivered

Two front controllers share one framework and database: every request except /administrator boots the public portal; admin URLs boot the entity CRM back office. Search criteria live in session so results, availability and the customer account reuse the same stay. Admin UI is metadata-driven (entities, fields, layouts, menus) so reservations, invoices and CMS share one shell.

Public portal ──┐
                ├── CodeIgniter / HMVC ──► PostgreSQL + PostGIS
Operator admin ─┘

Property & unit hierarchy

Portfolio / operator catalogue
   │
   ├── Property A ── Room / apartment types
   ├── Property B ── Villas / units
   └── Property C ── Rooms
          │
          ├── Seasonal prices
          ├── Packages
          └── Availability → Reservation

The same hierarchical model supports hotels, apartments, villas, rental portfolios and serviced residences. Project DB snapshot: 96 properties · 462 rooms · 50 reservations · 296 CMS pages · 1,774 UI strings (shipped dataset, not live-traffic claims).

Property management lifecycle

Hospitality (shipped direction)

Property → Unit/Room → Availability → Listing → Booking
  → Reservation → Payment → Stay → Invoice → Review

Long-term rental (future extension)

Property → Unit → Tenant → Lease → Rent
  → Maintenance → Renewal → Move-out

Direct booking engine & public portal

Give operators a branded booking experience rather than relying exclusively on third-party marketplaces. Header: language switch, destination menu, four-step search (type, destination, dates, guests). Results sort by price or stars; property pages expose availability, description, services, conditions, contacts and gallery.

Search → Destination → Dates → Guests → Availability
  → Pricing → Property → Room/Unit → Reservation → Payment

Future booking extensions (not claimed as shipped): dynamic pricing, coupons, taxes, deposits, cancellation rules, availability locks, automated confirmation.

Public homepage with language switch, destination menu and four-step accommodation search
Search results with filters, prices and property cards
Hotel property page with availability tabs and room types
Customer account with reviews, reservations and settings

Property management back office

Sidebar modules: structures, rooms, seasonal prices, packages, reservation board (current, projected, past, awaiting payment), customers, invoice generation with CSV export, CMS pages, news, media, reviews and translation catalogue. Property context scopes rooms and summaries; unpaid listing fees and missing rooms trigger publish warnings.

Administrator login screen
Admin dashboard with operational sidebar
Reservation board with timeline and payment queues
Invoice register with generate and CSV export
Property catalogue grid with type, city and stars
Room and apartment administration for selected property
Customer register with language and contact fields
Package editor with extras and validity period
Operational summary with publish warnings and upcoming stays

Billing & property-level payments

Invoices generate from the reservation workflow with CSV export for ops. Property-level payment methods in this build included PayPal, UniCredit, Sparkasse and bank transfer—configured per property rather than a single global gateway.

Multi-language property platform

IT · DE · EN with 1,774 UI strings, a translation catalogue and multilingual CMS—valuable for tourism, international hotels, vacation rentals and expat-facing real-estate portals. Languages exist at both UI and content levels.

CMS page editor with layout and multilingual content
Translation catalogue for UI strings
News article with related posts and weather widget

Location-aware property management (PostGIS)

PostgreSQL + PostGIS stores property geography—not only a pin on a marketing map. Reusable for nearby search, destination filters, clusters and service-area style queries across hospitality and real estate.

Property → Lat/Lng → PostGIS
              │
     ┌────────┼────────┐
     ▼        ▼        ▼
  Nearby   Geo search  Map ops

Channel manager & OTA — future extension

Not claimed as shipped. Modern vacation-rental buyers often expect two-way sync of availability, rates and reservations across channels.

Property Platform → Channel Manager
       │
  Airbnb · Booking.com · Agoda · MakeMyTrip · Direct

Real estate property management — future extension

Modernization path, not original tourism features: buildings/units/documents; tenant KYC & leases; rent/receipts/owner statements; maintenance work orders & vendors; portfolio occupancy, vacancy and yield.

Maintenance sketch (future)

Tenant/Staff → Maintenance request → Classify priority
  → Vendor → Work order → Complete → Invoice

Possible India-focused modernization (not claimed as shipped): UPI, GST invoices, TDS, tenant KYC, digital agreements, WhatsApp ops, Indian OTA connectors.

AI-powered property management — future architecture

Not claimed as shipped in this project. Potential evolution on a modern Property API:

  • Guest / tenant agent — availability, pricing, policies, check-in, maintenance Q&A
  • Leasing agent — qualify inquiries, schedule viewings, CRM follow-up
  • Maintenance agent — classify urgency, create work orders, notify
  • Portfolio ops — vacancy summaries, exceptions, payment reminders (assistive)

AI Voice for property (future)

Phone → AI Voice → Intent / Identity → Property API
  → CRM / PMS workflow → Human approval when required

Examples: “Is apartment 302 available next month?” · “The AC isn’t working.” · “When is rent due?” AI handles repetitive intake; humans approve lease decisions, rent changes, expensive repairs, refunds and sensitive exceptions.

Private property knowledge (RAG — future)

House rules, leases, amenities, maintenance manuals and FAQs → document processing → embeddings → RAG assistant for staff/guests/tenants. Links AI & Data, AI Voice and AI Automation.

IoT / smart property (future)

Sensors (HVAC, water, energy, access, occupancy) → gateway → event pipeline → alerts / maintenance / analytics. Labeled extension only.

Modern architecture path

Web / Mobile / AI Voice → API Gateway
  → Property · Booking · CRM services → PostgreSQL + PostGIS
  → Redis · Queues · Search → AI · Payments · Notifications

Typical rebuild stack: Next.js/React PWA · NestJS or FastAPI · PostgreSQL/PostGIS · Redis · async workers · optional pgvector/Neo4j for RAG. Historical evidence remains CodeIgniter + Metronic admin.

Legacy property platform modernization

Original stack: PHP 5.6 · CodeIgniter 2.1 · HMVC. Passwords were MD5—documented as upgrade debt, not a pattern to copy. Preserve the domain model and workflows; remediate security; add an API layer, modern frontend, mobile, cloud and optional AI.

Legacy PMS → Audit → Security remediation → API layer
  → Modern frontend → Mobile → Cloud → AI / automation

Screenshots (working application)

Captured from the working application (local dataset). Public booking first, then operator administration—evidence kept; narrative repositioned around property management.

My role

  • Solution architecture — dual portal, booking engine, multi-property catalogue, payment methods
  • Backend — CodeIgniter HMVC, PostgreSQL/PostGIS, session search, reservation board
  • Admin / CRM — metadata-driven entity grids, invoices/CSV, packages, seasons
  • Content & i18n — CMS, news, reviews, IT/DE/EN translation catalogue
  • Geospatial — property geography on PostGIS
Booking enginePMS back officeEntity CRMPostGISMultilingual CMSInvoicingSeasonal pricingDual portal

Technology stack

PHP 5.6CodeIgniter 2.1HMVCPostgreSQLPostGISjQueryMetronic adminSwift Mailer

Outcomes

  • One application covers traveller journey and operator journey: search → reservation → account → property ops → billing → CMS → three languages
  • Catalogue metrics above reflect the shipped project database—not live traffic claims
  • Clear modernization path to multi-property real-estate SaaS, channel sync and AI Voice—without pretending AI already shipped
FAQ

Property management & booking questions

PMS, booking, multi-property and modernization—telecom FAQ leftovers removed.

Property management software (PMS) coordinates properties, units/rooms, availability, reservations or leases, customers/tenants, billing, operations content and reporting—so multi-property businesses run digitally instead of spreadsheets and disconnected booking tools.

A PMS is the operational core: catalogue, inventory (rooms/units), calendars, bookings or leases, CRM, invoices and staff workflows. A booking engine and CMS often sit beside it; channel managers sync OTAs when needed.

Yes. This case study’s project database includes 96 properties and 462 rooms under one operator back office, with property-scoped rooms, packages and publish warnings.

Yes. The delivered hierarchy is property → rooms/apartments with seasonal prices and packages. The same model extends to villas, units and portfolio buildings in a modernization.

Yes. The public portal supports multilingual search (type, destination, dates, guests), filters, property dossiers with availability and customer accounts—direct booking on the operator’s own site.

PMS runs your inventory, reservations, guests and billing. A channel manager syncs rates/availability/reservations with OTAs (Airbnb, Booking.com, etc.). This case study documents direct booking + PMS; OTA sync is a labeled future extension.

As a future extension via a channel-manager layer (two-way inventory, rates, reservations, cancellation sync). Not claimed as shipped in the original tourism delivery.

The shipped product is hospitality short-stay (search, seasons, reservations). Tenant/lease/rent/maintenance workflows are documented as a real-estate modernization path—not original features.

Not in the original tourism build. Maintenance/work-order flows (with optional AI classification) are described as a future real-estate extension.

As a future architecture: guest/tenant Q&A, leasing qualification, maintenance intake, reminders and portfolio summaries calling the same property APIs—with humans approving leases, refunds and expensive repairs. Not claimed as shipped here.

As a future extension: voice for availability, viewings, maintenance intake and status—wired to Property/CRM APIs with human escalation. This case study does not claim AI Voice was in the original delivery.

Yes. This build ships IT · DE · EN with 1,774 UI strings, a translation catalogue and multilingual CMS pages/news.

Yes. This page documents a working CodeIgniter 2 / PHP 5.6 domain model (including MD5 password debt). Modernization preserves workflows while adding API-first services, secure auth, mobile and AI—see the legacy section.

The domain model (multi-property catalogue, booking, CRM, billing, CMS, i18n, PostGIS) is a strong SaaS foundation. Productization needs tenancy, packaging and ops hardening—see SaaS development.

Property types (hotel, vacation rental, residential), multi-property scale, direct booking vs OTA, languages, payment rails and whether you need AI Voice/maintenance later. Screenshots beat a long RFP. Email hello@unifiedpbx.in.

Building property management or booking software?

Share property types, multi-property scale, direct booking vs OTA needs, languages and whether AI Voice or maintenance comes later. The first reply maps PMS, booking, CRM and modernization boundaries.

Build a Property Platform