Evo Jet Services

EVO Jet Services is an aviation trip support company registered in Hong Kong, providing fuel pricing, ground handling, and flight support to Fortune 500 executive jet operators, cargo airlines, and government aircraft across 2,500+ locations worldwide.

CimpleO has built two systems for EVO on one shared Drupal backend: a client-facing mobile app for fuel pricing and ordering, and Flight Compass, an internal tool EVO’s own ops team uses to coordinate everything else a private jet trip needs on the ground.

Fuel pricing and ordering

The challenge

Aviation fuel procurement is time-critical and highly variable — prices change by location, availability, and supplier contract. EVO’s clients needed real-time access to fuel pricing and uplift ordering from their phones, without relying on phone or email back-and-forth with the operations team. The existing workflow didn’t scale with the volume of requests EVO was handling.

What we built

CimpleO delivered a mobile application and supporting Drupal backend for EVO Jet Services. The mobile app was built with Appcelerator Titanium, giving EVO a single codebase that ran natively on both iOS and Android — the right trade-off for a service used by flight crews and operations managers across different devices and operating systems.

The app gives authorised users direct access to fuel pricing by location, the ability to arrange uplift orders, and a clean view of transaction history. The Drupal backend manages the data layer, user authentication, and the administrative interface for the EVO operations team to manage locations, contracts, and account access.

Platform integrations

The platform connects to Fuelerlinx, FOS, and PFM — the major fuel pricing aggregators used across the aviation industry — so pricing data shown in the app reflects actual available rates. CimpleO implemented the API integrations for each provider, handling authentication, data normalisation across differing response formats, and the update frequency needed for time-sensitive pricing decisions.

Flight Compass: trip-support operations

The challenge

Coordinating a single international private jet trip means tracking a different checklist for every leg: overflight and landing permits per country, crew and passenger visas, fuel uplift, ground transportation, crew and passenger hotels, customs declarations, airport-specific briefings. Each of these has its own paperwork, its own status, and its own deadline relative to departure — and EVO’s ops team was coordinating all of it without a system built for the shape of that work.

What we built

Flight Compass models a trip the way EVO’s ops team actually thinks about it: a Trip (originally built as “Flight,” renamed once the team saw it in use) contains one or more Legs, and each Leg carries a set of Tasks — one per category of ground support the leg needs.

Task types, one content type per category of work:

• Flight Plan — route string, uploaded fuel release documents, airport briefing
• Permits — overflight and landing permission, tracked per country (the leg for a Moscow arrival needed a distinct “Russia Landing Permission” task from a Belarus overflight permit, for example)
• Visas — separate handling for crew (dropdown-selected from crew profiles) and passengers (free-entry passport details), each with passport number, nationality, issue and expiry dates
• Fuel — into-plane agent, estimated uplift volume, fueling location, linked to the same fuel-pricing system the client-facing app uses
• Ground Transportation and Crew/PAX Hotels
• Shipping Item to Aircraft — with airway bill upload and tracking number
• General Declaration — customs paperwork

We built this as a genuine data model, not a set of form fields bolted onto Drupal’s defaults — the entity structure (Trip → Leg → Task, plus a Locations taxonomy carrying runway specs, operating hours, time zone, and country-level notes on things like road safety) was mapped out and agreed with EVO’s team via a shared entity diagram before a line of code was written.

A dedicated Flight Compass Operator role gives EVO’s ops staff task-level access without exposing the rest of the site’s administration, and legs display using the airport codes and city names ops staff actually use — “DEP: LKPR (Prague) ARR: UUEE (Moscow)” — rather than internal IDs.

Extending the fuel API for tax reporting

One of EVO’s own downstream pricing partners needed fuel quotes broken out by tax component rather than as a single total — VAT, up to five named local taxes, and a base price, split separately for private/commercial and international/domestic flight types. Rather than change the API every other integration already depended on, we shipped it as a parallel endpoint (request_fuel_price_taxes.json alongside the existing request_fuel_price.json) returning the same per-supplier price tiers with the tax breakdown appended — so the one partner that needed it got it without any risk to the integrations that didn’t.

Results

The project required close coordination between the mobile frontend, the Drupal API layer, and the external data providers — QA covered both functional correctness and integration reliability, because a fuel order that fails silently has real operational consequences for a flight crew on a tight schedule.

Flight Compass turned a checklist that used to live across email threads and spreadsheets into a system where every task on every leg of a trip has an owner, a status, and a place EVO’s ops team can find it. It runs on the same Drupal backend as EVO’s client-facing fuel platform, so the two systems share pricing and location data instead of maintaining it twice.