The MoovLogic Platform

MoovLogic is the only branded ground-transport dispatch platform we are aware of running on Microsoft's newest long-term-support runtime end-to-end across every service. This page explains what that means in practice — for the operators who run the platform, and for the global distribution systems and online travel agents who consume our APIs.

The four eras of dispatch technology

Every dispatch platform in the world falls into one of four technology eras. The era determines almost everything that matters operationally: response time, reliability, cost to operate, ability to integrate, and how much engineering runway the platform has left before it must be rebuilt.

The honest market observation is that almost every named branded dispatch competitor sits in the second era. Cordic, the pre-Uber Autocab, the iCabbi platforms that came out of the 2010s acquisitions — all are variants of the same Microsoft-Framework stack the industry has been running for a decade. The third-era polyglots tend not to be branded dispatch SaaS; they are vertical marketplace players or in-house systems at the largest operators.

What we run on

For partners evaluating us as a technology supplier, this is the complete top-to-bottom answer. Every choice in this table is defensible against scrutiny. None of them are trendy bets that will look bad in three years.

For Amadeus and global distribution systems

Amadeus is the world's largest GDS, processing roughly 600 million booking requests every day across air, rail, hotel, and ground transport. When Amadeus integrates a ground-transport supplier, the supplier's API has to meet specific operational characteristics or that supplier gets quietly downranked in result sets. The thresholds are not contractual — they are competitive. Slow suppliers lose volume to fast ones.

In one line: we are not "an Amadeus integration." We are an Amadeus-shaped piece of infrastructure that happens to be ours. Many regional competitors who claim Amadeus compatibility are running PHP scripts that translate Amadeus XML to MySQL on every request. The latency and error-rate gap is significant.

For Booking.com and online travel agents

Booking.com's ground-transport division is the largest OTA channel for airport transfers globally. Their volume profile differs from Amadeus's — lower per-request value but much higher request frequency, with strong reward signals for price freshness and booking deliverability.

The AI-ready foundation

The AI conversation in dispatch is currently dominated by competitors slapping ChatGPT widgets onto legacy systems and calling them "AI-powered." This is theatre. Real AI in a dispatch platform requires three things, all of which MoovLogic already has:

1. Embeddings stored next to the operational data — so you can ask "find me the bookings most similar to this complaint" or "score this driver's behaviour against the cohort" in milliseconds against the same database that runs the rest of the business. We have this via PostgreSQL 16's pgvector extension.
2. Provider-agnostic abstractions — so when a new model ships, or a regulator forces us to switch to a sovereign-cloud model, we change one line of configuration. We have this via Microsoft's Microsoft.Extensions.AI, which reached stable 1.0 in .NET 10.
3. Observability — every AI call should be traced, costed, and audited the same way every other call in the platform is. We have this via OpenTelemetry instrumentation and our existing structured-logging pipeline.

AI in production today — Smart Driver Assignment

The first AI feature to ship is Smart Driver Assignment — a recommendation engine built directly into the dispatch board. When a dispatcher opens an allocated job, a single click asks Claude (Anthropic's AI model) to analyse every available driver and recommend the best match. The response arrives in under two seconds and looks like this:

The difference between this and Google Maps routing — which only asks "who is nearest?" — is that Smart Driver Assignment scores every available driver across eight simultaneous dimensions:

How it works technically

Every recommendation is produced by Claude Haiku (Anthropic) as the primary model, with OpenAI gpt-4o-mini as automatic fallback, and a deterministic rule-based scorer as final fallback if both AI providers are unavailable. The dispatcher is never blocked.

Every recommendation is logged to the database — the driver, the confidence score, the reasoning, the model used, token counts, and latency. Every accept or override is recorded. This creates a growing audit trail that will be used to measure recommendation quality and, in a future release, to fine-tune the prompt using real outcome data.

What's coming next

• Natural-language dispatch search — type "all Heathrow pickups tomorrow without a driver" instead of using filter dropdowns.
• Semantic booking history — search past bookings the way you think about them, not the way they're stored.
• Proactive flight-delay rebooking — AI detects a delay, adjusts the driver, sends a passenger message — before the dispatcher knows.
• Anomaly detection — nightly AI analysis flags unusual cancellation patterns, zone gaps, or driver behaviour outliers.
• Outcome learning loop — recommendation quality improves automatically as completed job data feeds back into the scoring model.

Risks we've designed out

How we maintain the lead

The technology stack is the visible tip of a much larger discipline iceberg. A team that lets technology rot is a team that lets everything else rot. Things we do that most competitors don't:

• 23 services, one shared library, no duplicated business logic. Pricing logic exists once. Address validation exists once. Authentication exists once.
• No hard deletes anywhere on the platform. Every entity has a soft-delete flag. The audit trail is complete by design.
• Every page logs every handler entry, validation failure, success, and exception to a structured database table that operations can query in SQL.
• Nine languages from day one, maintained by the same engineers who ship the features.
• Every architectural decision saved as a written plan to disk before code is written.
• Rules-as-code: the project has 40+ documented architecture rules, each with strictness triggers, that are checked by automated agents before code is merged.
• Two consecutive major .NET migrations completed in 18 months — Framework 4.8 to .NET Core 8, then .NET Core 8 to .NET 10. The most recent migration was completed in a single working day with no production incident.