Search-oriented service architecture
More than 45 service-area routes were structured so customers could reach relevant information for the locations they were actually searching for, instead of forcing every search intent through one generic page.
Case study
A booking platformbuilt for Detroit demand.
A production transportation website designed to help airport and city-service customers understand coverage, build trust and move into a clear booking journey while giving the operator a practical foundation for managing inquiries.
The project story
Problem, approach and working solution.
The challenge
Metro DTW Black Cars needed more than a brochure website. The product had to explain premium transportation services, support booking inquiries, create useful entry points for many Detroit-area service locations and run reliably on production infrastructure without making day-to-day management unnecessarily complex.
How Codantix approached it
Codantix treated the project as a connected customer-acquisition and operations system. The public experience was organized around airport travelers, fleet confidence, service coverage and booking intent, while the application structure supported admin workflows, automated communication and maintainable deployment behind the scenes.
Delivery evidence
How the production system came together.
Architecture, search, booking and deployment decisions were treated as one connected delivery problem.
Booking and admin workflows
Customer booking flows were connected to administrative routes so inquiries could move from the public site into an operational workflow rather than ending as disconnected page content.
Production infrastructure
The Next.js application was deployed behind Nginx with PM2 process management and TLS, creating a production setup that could be maintained independently of a managed frontend hosting platform.
Operational communication
Booking-related communication was built into the application flow so customer and operational handoffs could be handled as part of the system rather than as a separate manual process.
Constraints we designed around
- The experience had to work well for travelers using mobile devices and making time-sensitive transportation decisions.
- Location coverage needed to be useful for search without turning the site into a collection of disconnected or duplicate pages.
- The production setup needed to remain maintainable on a resource-conscious VPS environment.
- Customer-facing booking flows and administrative functionality had to stay understandable as the service-area footprint expanded.
What was built
A practical system shaped around real use.
The scope below describes product capabilities and delivery responsibilities without inventing performance claims.
Responsive transportation website built with Next.js
Customer booking flow with operational handoff
Admin routes for booking visibility and management
More than 45 service-area pages for relevant local coverage
Production deployment with Nginx, PM2 and TLS
Automated booking communication and search-ready technical routes
Operational value01 02 03
Clearer conversion path
Visitors can understand the service, verify coverage and move into the booking process without unnecessary friction.
Local search foundation
Dedicated service-area routes create relevant entry points for travelers and customers across the Detroit region while remaining connected to the main service experience.
Operational control
Admin and booking functionality provide a stronger foundation for handling customer inquiries and future operational improvements.
What the project taught us
Reusable lessons from a real production build.
Strong case studies should document decisions and constraints, not only show a finished interface.
Local SEO works best when the page solves a real visitor question
Service-area pages are more defensible when each route helps a traveler confirm coverage, understand the service and take the next step, rather than existing only to repeat a location keyword.
Conversion and operations should be designed together
A booking form is only the front half of the workflow. The system also needs a clear destination for the inquiry, operational visibility and communication after submission.
Production infrastructure is part of product delivery
Reverse proxy configuration, process management, TLS and deployment ownership affect reliability and handover just as much as the visible interface.
Technology and services
The capabilities behind the release.
Technology choices followed the user workflow, operational constraints and maintainability needs of the project.