Building the CMS for Next-Gen Mobility: Our Approach to Scalable Transit Software Architecture

The four assets share a category structure — an intent-heavy audience arriving from search, a booking flow, an operator-agnostic inventory model, and an editorial layer that establishes authority in the market. They differ in language, regulator, modality and demand shape.

So the architecture separates three things cleanly:

• Market configuration — locale, currency, regulatory copy, operator set, modality.

• Domain logic — itineraries, inventory, pricing, settlement, disruption handling.

• Presentation — per-market editorial content and conversion surfaces.

The editorial system is not a blog bolted on for SEO theatre. It is the mechanism that builds topical authority before any transaction exists, and it is structured accordingly: typed post schemas, per-post metadata and canonical handling, structured data for article and organisation entities, category clustering, and full multilingual routing with hreflang alternates.

On robotaxi.tokyo this already runs in production across a large post catalogue with English and Japanese locale routes at /en and /ja, per-locale canonicals, and dynamic language attribution.

Under design and partial build, with the model deliberately chosen to fit both ground and aerial modalities:

• Itinerary as the primary object, with legs derived rather than authored.

• Operator-agnostic inventory adapters, so adding a fleet or an aircraft operator is a configuration task.

• Slot-aware capacity for aerial legs, dispatch-aware capacity for ground.

• Micro-transaction settlement with per-party splits and reconciliation.

• Deterministic disruption logic including automatic ground substitution.

• AI concierge routing as a planning service that consumes the same inventory API as the booking UI.

No live rider bookings. No signed operator integrations. No fleet, no aircraft, no vertiport agreements. We are an independent development team building the digital layer and holding the category namespaces it would run on.

We say this explicitly because an acquirer's diligence will establish it anyway, and because the value proposition does not depend on overstating it. What is being offered is a defensible digital position plus a working framework — not a revenue-generating operator.

For operators, airlines or consortiums who want the architecture documentation, repository walkthrough and asset schedule: andrew.mc@nousdomains.com.