Case study · Website modernisation, content platform, catalogue, booking application, and media infrastructure

Luxorides Digital Platform

A multi-application digital platform combining a modern public website, visual content management, product listings, page-level SEO, secure media delivery, legacy-route compatibility, and a Fleetovo-powered customer booking application.

LiveProgressive migrationContent platformCustomer booking

Amit's role: Technical Head / Full-Stack Developer
Project type: Website modernisation, content platform, catalogue, booking application, and media infrastructure
Organisation: URV India Pvt. Ltd.
Team context: Company product · contribution within URV India Pvt. Ltd.

Primary technologies

Next.js
Tailwind CSS
MySQL
Prisma ORM
Puck Editor
Spring Boot
Fleetovo APIs

Product destinations

Public homepage

Outcome snapshot

The project in operational terms.

Scope, complexity, responsibility, and business outcomes are described without unsupported statistics.

What was built?

A Next.js website, Next.js administration platform, Puck-based visual page system, central product catalogue, page-level SEO controls, legacy-page registry, self-hosted media service, and Fleetovo-backed customer application.

Who uses it?

Public visitors and customers use the website and booking application; authorised editors and administrators manage content, products, SEO, redirects, and media.

Why does it matter?

The platform needs to modernise an established website without breaking valuable HTML routes or forcing an immediate full migration.

What did Amit own?

Amit connected architecture, implementation, Figma design coordination, reusable Puck sections, content, SEO, products, legacy routes, media, and booking requirements.

What changed?

Luxorides can modernise progressively while managing modern pages, products, metadata, redirects, media, and customer bookings through maintainable systems.

Business and operational context

Understand the operation before the technology.

The existing Luxorides website contains static HTML pages with established URLs. Removing them during a full rewrite would risk breaking links and discarding useful route history.

The modernisation strategy therefore treats legacy compatibility as an architectural boundary: required HTML pages can continue to be served, modern pages can replace them gradually, and deprecation or redirects can be controlled rather than improvised.

Product scope

Product capabilities.

Capabilities describe the product; Amit's contribution is documented separately below.

Public website and progressive migration

Next.js and Tailwind CSS modernise the public experience without deleting required legacy pages.

Preserve established URLs
Continue serving selected legacy HTML pages
Modernise routes gradually
Control permanent or temporary redirects where required

Administration and Puck page builder

A Next.js, MySQL, Prisma, and Puck administration platform shares the core website database.

Registered reusable website sections
Drag-and-drop composition and reusable templates
Publish supported page types to configured routes
Structured editing without changing source files for every page

SEO and product catalogue

Page metadata and product information remain centrally managed.

Per-page title, description, canonical URL, robots, Open Graph, structured data, and supported social metadata
Central product catalogue
Reusable featured-product sections
Editor-controlled product selection, order, and placement

Media and customer booking

Separate services support media delivery and operational customer workflows.

FiloraFS-Lite-based Spring Boot media and file service
Secure upload, retrieval, and controlled delivery
Fleetovo-backed customer bookings, history, payments, and invoice downloads
Consistent data between customer and employee systems

Personal contribution

Amit's contribution and responsibilities.

Leadership, implementation, and team contribution are described separately to avoid overstating individual ownership.

Architecture

Designed the progressive migration, shared content and product data, media-service, and Fleetovo integration boundaries.

Implementation

Continued hands-on contribution across the Next.js applications, reusable sections, administration workflows, SEO, and integration work.

Team leadership

Coordinated developers implementing approved designs and reviewed reusable component and page-template consistency.

Delivery coordination

Connected Figma design, content, SEO, product, administration, media, legacy-route, redirect, and customer-booking requirements.

Production ownership

Maintains compatibility between established HTML routes and modern Next.js pages through controlled migration and redirect decisions.

Stakeholder collaboration

Converted business requirements into implementation-ready sections and page templates and coordinated the design team preparing Figma designs.

Constraints

The boundaries that shaped the work.

These are product and delivery constraints, not a disclosure of private production configuration.

Constraint 01

Established routes

Valuable public URLs must not disappear during modernisation.

Constraint 02

Supported composition

Administrators compose registered sections and supported page types, not arbitrary executable code.

Constraint 03

Shared content truth

Products and page-level SEO should remain central rather than duplicated across routes.

Constraint 04

Media isolation

File storage is separated from the public web application and is not described as a global edge CDN.

Constraint 05

Authenticated administration

Administration and internal media controls are not presented as unrestricted public applications.

System architecture

Progressive legacy-to-modern platform architecture

A static, keyboard-inspectable model with visible relationships and a complete text alternative.

Architecture model

Luxorides progressive migration architecture

Modern and legacy delivery coexist behind controlled route and content decisions.

Layer 01

Public and customer experiences

Modern, legacy-compatible, and booking surfaces.

Next.js public website
Modern pages, catalogue presentation, metadata, and responsive UI.
Selected legacy HTML
Required established pages served during progressive migration.
Customer booking application
Fleetovo-backed bookings, history, payments, and invoices.

Layer 02

Administration platform

Structured content and route management.

Puck page builder
Registered sections, templates, and configured routes.
SEO & redirect management
Page-level search, social, schema, and route controls.
Product catalogue
Central products and reusable featured-product sections.

Layer 03

Data and services

Shared persistence and isolated operational services.

MySQL & Prisma
Core website, page, product, metadata, and redirect data.
FiloraFS-Lite media service
Self-hosted Spring Boot upload, storage, retrieval, and delivery.
Fleetovo APIs
Operational customer booking and financial records.

Relationships

Puck page builderNext.js public websitepublishes supported page models
SEO & redirect managementModern and legacy routescontrols metadata and migration behavior
Product catalogueNext.js public websitesupplies central product content
FiloraFS-Lite media servicePublic and administration platformsstores and delivers controlled media
Customer booking applicationFleetovo APIsuses shared operational data

Text alternative

The public Next.js website serves modern routes and supported legacy HTML pages. An authenticated Next.js administration platform uses MySQL, Prisma, and Puck for pages, products, metadata, and redirects. FiloraFS-Lite provides isolated media storage and delivery. The customer application uses Fleetovo APIs for bookings, payments, history, and invoices.

Visual evidence

Reviewed product interfaces.

Public screenshots are presented in full without cropping. Private product images use opaque, irreversible redaction.

Luxorides vehicle catalogue and car exploration interface — Vehicle discovery

Luxorides vehicle product details page — Product presentation

Key decisions

Trade-offs, not slogans.

Each decision records what was selected, what was considered, and the cost accepted.

Decision 01

Choose progressive migration

Why selected: Established HTML URLs retain value and cannot all be modernised safely at once.
Alternative considered: Delete legacy pages and force an immediate full rewrite.
Trade-off accepted: Modern and legacy delivery must coexist temporarily.
Current result: Routes can be modernised in controlled stages without abandoning required pages.

Decision 02

Register supported Puck sections

Why selected: Editors need flexibility while design and implementation remain consistent.
Alternative considered: Allow arbitrary code or page markup.
Trade-off accepted: New page capabilities require deliberate component registration.
Current result: Administrators compose approved page types from reusable sections.

Decision 03

Separate media storage

Why selected: Public rendering should not own file-storage infrastructure.
Alternative considered: Store upload logic directly inside the website application.
Trade-off accepted: A separate service adds API and operational boundaries.
Current result: Website and administration applications share controlled file APIs through a self-hosted media service.

Selected implementation

Safe examples of system behavior.

These examples are simplified and generic. They contain no credentials, client data, internal URLs, or confidential production code.

Example 01

Legacy-to-modern route lifecycle

Controlled migration preserves route behavior.

01
Inventory legacy page
Record route, content value, and migration state.
02
Continue serving when required
Keep approved HTML pages available.
03
Publish modern route
Build the supported page from registered sections.
04
Deprecate or redirect
Apply controlled permanent or temporary behavior where required.

Example 02

Visual page publishing

Administrators publish supported page types rather than arbitrary code.

01
Compose registered sections
Use reusable Puck components and templates.
02
Configure content and products
Select central catalogue data and page content.
03
Manage page SEO
Set page-specific search, social, canonical, robots, and schema fields.
04
Publish configured route
Make the approved page model available to the website.

Impact

Qualitative, evidence-based outcomes.

01Allows Luxorides to modernise without abandoning established HTML routes.
02Creates maintainable systems for page composition, SEO, products, media, redirects, and customer bookings.

Reflection

What the work teaches next.

What worked

Treating legacy compatibility, structured content, and operational booking as separate boundaries made gradual delivery possible.

What was difficult

Routes, page models, products, SEO, redirects, media, design, and customer data must evolve without contradicting one another.

What could improve

Continue documenting component contracts, migration states, and content ownership.

Next architectural step

Modernise remaining approved legacy routes through the same inventory and redirect workflow.

Current status

Status stated without inference.

Production digital platform with a public website, authenticated administration, customer booking application, self-hosted media service, and progressive legacy-page migration.