KVN
System registry
SYS-0082026-07–present

Rental Operations Platform

An anonymous production rental platform centered on the back-office rules behind vehicles, pricing, locations, availability, reservations, and staff access.

TypePlatformEngagementClientTierCase StudyStateProductionActivityActive Development
01

Context

Rental Operations Platform combines a public booking website with an application-owned API and a custom operational console. Staff can maintain vehicles and media, seasonal price overrides, one-way location fees, availability blocks, reservations, offers, site content, users, and scoped access. The public site consumes the same authoritative pricing and availability behavior without owning those business rules itself.

Core engineering problem

Keep public rental discovery and booking connected to one maintainable source of operational truth for vehicles, rates, locations, availability, reservations, and staff responsibilities.

A rental website is only the visible edge of the system. Day-to-day operation depends on changing inventory, seasonal exceptions, inter-location fees, unavailable periods, reservation state, and different staff responsibilities. The case study focuses on that back-office model rather than the operator's identity.

  • Keep authoritative availability, pricing, and reservation totals on the backend.
  • Preserve the price quoted at booking even when later vehicle or pricing configuration changes.
  • Prevent overlapping active reservations and internal vehicle blocks from producing false availability.
  • Let seasonal overrides coexist without destructively rewriting a vehicle's fallback rate.
  • Keep staff access scoped by operational area and distinguish view from manage permission.
  • Keep customer identity, operational data, configuration values, routes, and infrastructure identifiers private.
02

My role

I designed and implemented the software system: its public site, Django API and data model, custom back-office, operational rules, notifications, deployment, testing, and ongoing maintenance.

Contribution boundaries

  • Customer IdentityThe rental operator, associated business, personal relationship, and commercial arrangement remain anonymous.
  • Software ScopeI'm responsible for the software system, not for the customer's rental-business operations.
  • Payment ScopeOnline payment integration is future work and is not presented as an implemented capability.
  • Future Product DirectionThe existing back-office model could later inform a generic rental-management product, but the current implementation is not presented as SaaS.
Architected

System And Domain Design

Public-site, API, back-office, vehicle, location, pricing, availability, reservation, content, and permission boundaries.

DesignedArchitectedModelledImplementedReviewed
Designed

Back Office Engineering

Vehicle and media management, pricing rules, location tariffs, availability, reservations, roles, permissions, settings, and content administration.

DesignedImplementedMaintainedReviewed

Public Application

Public vehicle discovery, availability, quotation, reservation, content, and bilingual delivery against the same backend contracts.

DesignedImplementedIntegratedMaintained
Implemented

Delivery And Operations

Containerized runtime, persistent database and media, health checks, routing boundary, reservation notifications, and production operation.

ImplementedDeployedOperatedMaintainedReviewed
03

Architecture

Level 01 / System

Public booking and back-office boundary

09 boundaries · 10 declared relationships

  1. 01Public rental customerClient
  2. 02Authorized operations staffClient
  3. 03Bilingual public websiteService
  4. 04Custom operations consoleService
  5. 05Django rental API and servicesAPI
  6. 06Operational data storeDatastore
  7. 07Persistent vehicle mediaDatastore
  8. 08Email and browser push deliveryExternal Provider
  9. 09Containerized production runtimeInfrastructure
Relationship mapInspect 10 connections
  • Public rental customerRequestBilingual public website
  • Authorized operations staffRequestCustom operations console
  • Bilingual public websiteRequestDjango rental API and services
  • Custom operations consoleRequestDjango rental API and services
  • Django rental API and servicesPersistenceOperational data store
  • Django rental API and servicesPersistencePersistent vehicle media
  • Django rental API and servicesNotificationEmail and browser push delivery
  • Containerized production runtimeHostingBilingual public website
  • Containerized production runtimeHostingDjango rental API and services
  • Containerized production runtimeHostingOperational data store
04

Engineering decisions

01

Resolve daily prices from fallback rates and explicit overrides

Context

Most dates can use a vehicle's ordinary rate, while seasons and exceptional periods need different prices.

Selected approach

Keep a fallback daily rate on each vehicle and select the most recently created matching date rule for each charged day.

Rationale

Let staff add or supersede exceptions without destructively rewriting the baseline or older rules.

Trade-offs

  • Overlapping rules require a clear winner and an admin view of shadowed rules.
  • A multi-day quote may contain several price segments.
02

Store one fee for each unordered location pair

Context

A one-way rental between two branches uses the same surcharge regardless of travel direction.

Selected approach

Canonically order each pair and maintain one active fee record, including reviewable zero-value placeholders for new locations.

Rationale

Prevent conflicting A-to-B and B-to-A configuration while keeping missing decisions visible to staff.

Trade-offs

  • Pair ordering must be enforced consistently.
  • Adding a location creates configuration work across existing branches.
03

Keep availability and quotation authoritative on the server

Context

Public search, direct vehicle entry, and staff-created reservations all depend on the same operational rules.

Selected approach

Check active reservation and vehicle-block overlap in backend services, recompute the quote, and persist a booking-time snapshot inside a transaction.

Rationale

Prevent browser-calculated prices or stale availability from becoming the operational source of truth.

Trade-offs

  • Quote logic must remain centralized as new pricing rules are introduced.
  • Calendar-day overlap is deliberately conservative for same-day turnarounds.
04

Build a role-scoped operations console instead of exposing framework administration

Context

Staff responsibilities differ across reservations, fleet, locations, extras, offers, and content.

Selected approach

Use a custom back-office interface with section-level view/manage access and keep framework administration outside the public workflow.

Rationale

Match daily operational tasks while making staff access narrower and easier to review.

Trade-offs

  • The application owns more administrative interface code.
  • Every new operational area needs an explicit access mapping.
05

Runtime ownership

  1. 01
    Containerization

    The production stack separates the public site, API, and PostgreSQL services with health-gated startup.

  2. 02
    Reverse Proxy

    Host routing keeps the public site and application services behind a controlled delivery boundary.

  3. 03
    Hosting

    I deploy, operate, and continue improving the production platform.

  4. 04
    Storage

    PostgreSQL persists operational state while a dedicated volume preserves vehicle media across rebuilds.

  5. 05
    Logging

    Notification failures are logged without making them block reservation creation.

  6. 06
    Notifications

    Committed reservation changes trigger customer email and role-derived staff notifications.

    Inspect operational detail
    • Browser subscriptions that are permanently invalid are removed after provider feedback.
  7. 07
    Deployment

    Production services use health checks, restart policies, and loopback-only application exposure behind host routing.

06

Current state

  1. Current

    The platform is deployed in production, used by an anonymous rental operator, and remains under active improvement.

  2. Lesson

    A back-office designed around reusable rental concepts could later evolve into a generic product for other operators; that product does not exist yet.

Depth B / Technical inspection

Inspect supporting evidence

Domains, provider boundaries, and evidence classifications.

T1

Domain structure

  • Fleet and vehicle mediaVehicles, categories, specifications, status, ordered photos, fallback daily rates, and maintenance or out-of-service blocks.
  • Locations and one-way feesActive pickup and drop-off locations plus one canonical fee record for each unordered location pair.
  • Pricing and depositsVehicle fallback rates, date-based overrides, rental-length calculation, extras, one-way fees, and configurable security-deposit rules.
  • Availability and reservationsCalendar-day overlap checks, internal blocks, authoritative quotes, guest reservation details, status, and retained booking snapshots.
  • Back-office access and workflowsCustom staff console, operational dashboard, users, section-level view/manage permissions, settings, and reservation actions.
  • Public content and notificationsOffers, articles, FAQ content, bilingual public delivery, reservation email, and staff web-push notifications.
T2

Integrations

  • EmailReservation email delivery

    Confirm reservation receipt and later approval without making delivery part of the database transaction.

    Transactional email after committed reservation state changes
  • Push NotificationsBrowser Web Push

    Notify reservation staff of new bookings while pruning expired subscriptions.

    Standards-based web push to subscribed authorized staff devices
T3

Capability evidence

  • System architectureI designed the public site, shared contracts, Django API, custom operations console, persistence, media, and deployment boundaries.
  • API designI implement server-owned catalog, availability, quote, reservation, content, and operational interfaces.
  • Frontend deliveryI built the bilingual public website and the separate custom back-office interface.
  • Domain modellingI model vehicles, images, blocks, locations, pair fees, pricing rules, extras, deposits, reservations, content, and scoped staff access.
  • Transactional workflowsI create and update reservations transactionally while recalculating authoritative quotes and checking availability.
  • Authentication and authorizationI separate public booking from authenticated operations and apply section-level view/manage access in the custom console.
  • Systems integrationI deliver reservation email and standards-based browser push through application-owned notification boundaries.
  • Relational persistenceI persist operational configuration, reservation snapshots, staff access, content, and notification subscriptions in PostgreSQL.
  • Deployment and operationsI deploy and operate the containerized production site, API, database, and persistent media storage.
  • Automated testingI maintain regression coverage for pricing, availability, reservations, administration, permissions, content, and notifications.