Equiroute: booking transport for horses.
A transport and booking platform for moving horses, built with React, React Native and Django REST Framework. Owners book a journey within a city or between them, and the system matches it to operators equipped for live animal transport. It is a booking product whose cargo makes almost every ordinary assumption wrong.
The challenge.
- Transport was arranged through personal networks and phone calls, so an owner's options were limited to the operators they happened to know.
- The cargo is a live animal, so operator suitability is a hard constraint — vehicle type, ventilation, journey duration limits and handling experience — not a preference to sort on.
- Journeys vary enormously in shape, from a short local move to a long multi-stage route, and a booking model built around one of those handles the other badly.
- Owners are anxious in a way that ordinary logistics customers are not, so visibility during the journey matters as much as the booking itself.
Our approach.
- Modelled operator capability as structured attributes in Django REST Framework rather than free text, so matching a journey to a suitable operator is a query the system can answer instead of a judgement the owner has to make.
- Made journey duration and route a first-class part of the booking, because welfare requirements for live transport depend on time and distance rather than on price or convenience.
- Built the owner-facing app in React Native and the operator side in React, matching how each actually works — owners on a phone, operators managing a schedule at a desk.
- Treated the journey rather than the transaction as the object the interface is organised around, so status during transit is the default view instead of something to go looking for.
- Kept booking amendments and cancellations inside the system, since plans around animal movement change frequently and pushing that back to phone calls would have recreated the original problem.
The outcome.
- Owners reach operators beyond their existing personal network.
- Operator suitability is matched on structured capability rather than assumed.
- Short local moves and long multi-stage journeys are handled by the same booking model.
- Journey visibility is the default view, which is what owners actually want from the product.
Related travel & hospitality work.
TravelRoomora: global hotel reservations.
Travellers search, compare and book hotels from one mobile-first surface.
React · Django · Django REST Framework · PostgreSQL
TravelRihla: Travel platform.
A travel booking platform on React, Django, Django REST Framework and PostgreSQL. Search, live availability, booking and confirmation run end to end, so a reservation takes minutes rather than a chain of emails.
React · Django · Django REST Framework · PostgreSQL
TravelExcursia: Travel platform.
Built with React and Django over PostgreSQL to replace booking by phone and email. Availability is live, confirmation is immediate, and the operator stops re-keying every reservation by hand.
React · Django · Django REST Framework · PostgreSQL
Where AI fits in travel & hospitality.
Booking and guest assistants that work in English and Arabic, itineraries generated from live availability, and messaging that hands over to staff for anything unusual.
Explore AI developmentWe are a mental health charity and not tech-minded. We needed to improve our patient registration system but wanted a company that we can relate to. Hassan took the time to meet with me and patiently went through our process to find a personalised solution for us. Hassan's team did a great job streamlining our process and connected our registration system to our patient management software. Whenever we have a glitch, they resolve this quickly.
Questions about this build.
Still wondering something? Ask an engineer
The difference from general booking software is that supplier suitability is a constraint rather than a ranking. Capability has to be modelled as structured, queryable attributes so the system can exclude unsuitable operators outright, instead of listing everything and leaving the customer to work out what is appropriate. Getting this wrong turns a specialist marketplace into a directory.
Model the journey as a route with stages rather than as an origin and destination pair. A short single-leg move is then simply the trivial case of the same structure, instead of the model being built for one shape and awkwardly stretched to the other. This also makes duration-dependent rules — welfare limits, rest requirements — expressible against the booking rather than checked outside it.
Usually not, because they are genuinely different products serving different working contexts. Here the customer app is React Native for phone use, while the operator side is React for desk-based schedule management. What they must share is the API and the domain model — the expensive mistake is duplicating business rules across two clients, not building two interfaces.
Longer than a one-sided one, mostly because you cannot validate it until both sides exist. Our usual approach is to get the supply side working first, since a marketplace with no operators has nothing to test against. Scope depends heavily on how much of the matching logic is genuinely domain-specific, which in a specialist market like this is most of it.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.