Flight booking and travel
Search, booking and servicing built on top of a supplier's fare and availability feed — with the approval, payment and record-keeping around it belonging to you.
Talk about scopeMost of this system is somebody else's data
It is worth being blunt about the shape of this one. Fares, availability and fare rules come from a GDS, a consolidator or an airline directly, and that feed is authoritative — we are not building an inventory, we are building everything around one. That is a perfectly good project, and it is a different project from the others on this list: the risk sits in integration and in failure handling rather than in the domain model, and the schedule is set by how quickly a supplier will talk to you.
What makes it hard
You are building on inventory you do not own
Fares, availability and rules come from a supplier - a GDS, a consolidator or an airline API - and they are authoritative, not advisory. The realistic scope of a build like this is the search, the workflow and the record around that feed, and being clear about the boundary early is what keeps the estimate honest.
A quoted price is perishable
A fare found in search may be gone by the time someone clicks book, and the difference has to be handled in front of the customer rather than by silently re-pricing. The system needs an explicit revalidation step and a defined behaviour when the answer comes back different.
Booking is a multi-step transaction that can fail midway
Hold, price check, payment, ticket issue - each with its own timeout, across systems that cannot be rolled back together. The hard requirement is never leaving a customer charged without a ticket or holding a ticket nobody paid for, which means reconciliation and compensating actions rather than assuming success.
Where the work actually lands
Selling a ticket once is the demonstration. What follows it is the system.
The rules live in the fare, not in your code
Changes, cancellations, baggage and no-show penalties are attributes of the fare that was sold and vary by supplier and route. Storing what was actually purchased - the full rule set at time of sale - is what makes it possible to answer a change request eight months later without guessing.
Servicing is where the effort goes
Selling once is the demo. Changing a date, splitting a party, reissuing after a schedule change and processing a refund are the work, they involve the supplier again, and they are where every real support burden comes from.
Corporate travel is an approval system
Where a business is booking, the interesting logic is policy and authorisation - who may book what, above which threshold, and who signs it off - and that is a workflow and permissions problem of the kind we build routinely, sitting on top of the travel feed.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.