The systems behind the sell: inventory and availability that stay true across every channel, rate rules a revenue manager can actually change, a booking record that survives a schedule change, and the refund path that decides whether a cancellation costs you a customer. If what you want is a restaurant ordering app for a hotel outlet, the restaurant app page is the one you want.
The commercial facts in one block, so you never have to hunt for them. Booking engine development and hotel management software development meet at inventory, the one record that must never disagree with itself. Those tiles are: Typical integration set, Phase one timeline, Rate band, Phase one range, with the arithmetic, Stack we actually use and Our commitment.
Typical integration set
01A supplier or GDS connection, a channel manager pushing to OTAs, a payment gateway that can hold and release, and whatever the reservations team currently reconciles in. Plus the rate spreadsheet somebody maintains by hand.
Phase one timeline
023 to 5 months. The pacing constraint is supplier certification rather than engineering: every channel has its own test environment and sign-off, and those weeks are nobody's to accelerate.
Rate band
03$40 to $100 per hour by role. Reporting and admin near the floor, availability modelling and refund logic near the ceiling. Mixed teams blend to around $65.
Phase one range, with the arithmetic
04Discovery 90 plus inventory 240 plus rates 210 plus booking record 270 plus supplier links 250 plus payments 190 plus refunds 200 plus reconciliation 130 equals 1,580 hours. That runs $63,200 at $40 and $158,000 at $100, about $102,700 at a $65 blend. Full span 1,170 to 2,280.
Stack we actually use
05Postgres for inventory and orders, because availability is a concurrency problem before it is a product one. A queue in front of every channel, since they retry and they duplicate. Your existing payment provider, with authorisation and capture separated.
Our commitment
06No quote before discovery. We will also tell you when a channel manager you already pay for covers most of what you are asking us to build, which on this vertical happens more often than not.
Audience
Six operator shapes and the number each one cannot currently produce. Not a fit: if you want a consumer ordering app for a hotel restaurant, that is the restaurant app page, linked at the foot of this one. The shapes it fits are: You oversold on two channels at once and Rate changes take a developer.
Availability lives in three places and none of them is authoritative, so the same room or seat sells twice on a busy weekend. We start by making one inventory the source of truth and every channel a projection of it.
Seasonal rates, minimum stays and promotions are hardcoded, so revenue management files tickets instead of changing prices. We start by moving rate rules into data a non-engineer can edit safely.
The supplier moves a flight or a sailing and your record no longer matches theirs, so reconciliation becomes manual archaeology. We start with a booking record that can absorb a change without losing its history.
Cancellation policy lives in prose, agents interpret it differently, and the same case gets two answers. We start by encoding the policy so the system computes the entitlement and a human approves an exception.
A carrier or supplier is pushing you off legacy distribution and the answer to whether you support Offers and Orders is currently no. We start by scoping what actually changes, which is the order record rather than the search screen.
Combining flight, hotel and transfer makes you an organiser with insolvency protection and refund duties, and the rules were tightened in 2026. We start by mapping which of your combinations are legally packages.
Travel is one word for six businesses. What breaks is different in each, so what we build is different. This page covers: Hotels and groups, Tour operators, Online travel agencies, Airlines and air distribution, Ground transport and transfers and Activities and attractions.
01 · Your operation
What breaks
Channel parity, overbooking and a rate plan matrix that grew organically until nobody can explain a price. Group and corporate rates sit outside the system entirely.
What we build
One availability model with channel projections, rate plans as editable data, and controlled overbooking rather than accidental overselling.
The stages a booking moves through, and what we build at each one. In sequence, the stages are: Search and availability, Offer and pricing, Booking and payment, Fulfilment and documents, Change and cancellation and Settlement and reporting. Each one is a place a system either holds the fact or loses it.
Travel distribution is an inventory problem with a settlement problem attached. Here is the estate we expect to meet and the modelling decision that determines whether any of it reconciles. Grouped as: Legacy distribution, NDC and Orders and Channel managers and OTAs.
The GDS layer, Amadeus, Sabre and Travelport, still carries a great deal of traffic. Its shape assumes a passenger name record, a separately issued e-ticket and electronic miscellaneous documents for anything else, which is why an ancillary reconciles on a different path from the fare.
IATA's New Distribution Capability, not to be confused with a distribution company, is an XML standard for exchanging Offers and Orders directly rather than through legacy messaging. ONE Order consolidates the PNR, the e-ticket and the EMDs into a single Order record. IATA's Distribution Advisory Council holds an aspirational goal of 100% Offers and Orders by 2030, with the explicit caveat that this means the capability exists by then, not that the industry has moved. Most carriers are expected to transition around 2028 to 2029.
The layer that pushes availability and rates outward and pulls bookings back. Each channel has its own retry behaviour, its own idea of what a cancellation means, and its own certification before you may connect to production.
A hold reserves capacity without a contract and must expire on its own. Systems that only understand confirmed bookings either oversell while a customer is entering card details, or leak inventory when they abandon the cart. Model the hold explicitly with a timeout the business chooses.
A rate plan is the rule, a price is what that rule produced for a specific stay on a specific day through a specific channel. Store both. Keeping only the price makes a dispute unanswerable; keeping only the rule makes a historic invoice unreproducible.
The policy is what was agreed at booking. The entitlement is what this cancellation, at this moment, actually earns back. Compute the second from the first and store it on the booking, so an agent approves an exception rather than performing an interpretation.
Every supplier issues their own reference and some reissue it after a schedule change. Key your record on your own identifier and hold theirs as an attribute with history, or a supplier-side change quietly orphans your booking.
Name every system that holds a copy of what you can sell right now. If the answer is more than one, that list is the reason you oversold, and it tells us more than a requirements document would.
Consumer protection, card handling and data residency land on different teams and all three end up in the same booking flow. Each row is dated. Verify current status before contracting, because one of these changed in 2026. Covered here: EU Package Travel Directive, revised 2026, IATA distribution and settlement, PCI DSS v4.0.1 and Data protection across your markets.
The Council adopted the revision on 30 March 2026 and it became Directive (EU) 2026/1024 of 29 April 2026, with 28 months for member states to transpose, so national law lands around September 2028 and applies from 2029. The build consequences are concrete: vouchers may still be offered but acceptance must be voluntary and the traveller must be expressly told they can refuse and take a monetary refund instead, and where a supplier cancels or fails to deliver, they must refund the organiser within seven days. Combining a flight with a hotel or a transfer generally makes you an organiser, which brings insolvency protection with it.
Selling air on behalf of carriers brings accreditation and settlement obligations, and the messaging standard is moving. NDC exchanges Offers and Orders directly, and ONE Order collapses the PNR, e-ticket and EMD into one record. Plan for both worlds at once rather than a cutover: the aspiration is capability by 2030 and most carriers land around 2028 to 2029, so a system that can only speak one of the two will be wrong for several years in either direction.
All 51 future-dated requirements became mandatory on 31 March 2025, and multi-factor authentication now applies to all access to the cardholder data environment rather than only administrative accounts. Travel makes this harder than most retail because bookings are authorised early and captured late, sometimes weeks later, and because agents handle card details by phone. Keep card data out of your systems entirely and the assessment shrinks dramatically.
Oman's PDPL came into force on 13 February 2023 and treats cross-border transfer as needing express consent plus an adequacy assessment. India's DPDP Rules were notified on 14 November 2025 with full obligations by 13 May 2027. Passenger data is unusually mobile in this sector, moving between operator, supplier, channel and destination, so enumerate every hop and treat each as a transfer rather than as plumbing.
Air passenger compensation and assistance regimes, hotel guest registration requirements and local tourism levies all vary by jurisdiction and change without much notice. The architectural answer is the same in each case: keep the rule in a jurisdiction-scoped policy layer with its own adapter, so a new market is a configuration rather than a change to how bookings work.
Consumer protection, card scope and passenger rights all move on their own timetable and none of them should be threaded through the booking path. Keep each behind its own adapter and store the version of the policy that applied at the moment of sale, because a refund dispute two years later is judged against the terms in force then, not the terms in force now.
Ten failure modes with the counter-practice attached. Naming them is more useful than a list of reasons to pick us. It starts with: Availability cached as a copy of inventory, No hold semantics and Rate rules hardcoded. Each is written plainly enough that you can check whether yours is already happening.
The cache goes stale under load and the same unit sells twice on exactly the day it matters. Derive availability from inventory with holds applied, and choose the cache window against your real look-to-book ratio.
Capacity is either committed or free, so a customer entering card details is either blocking stock indefinitely or racing another buyer. Model the hold with an explicit timeout owned by the business.
Revenue management raises a ticket to change a price, so prices change late or not at all. Rate plans belong in data with a safe editor, not in a deployment.
A dispute arrives and nobody can reconstruct why that customer paid that amount through that channel. Store the offer and the rule alongside the price.
Two agents read the same terms and give two answers, and the difference is refunded from margin. Encode the entitlement and let a human approve exceptions rather than interpret rules.
The supplier reissues it after a schedule change and your record is orphaned. Key on your own identifier and keep theirs as an attribute with history.
Channels retry and duplicate, so one cancellation arrives three times and the third one refunds a booking that no longer exists. Make every handler idempotent on the channel's own reference.
Travel authorises early and captures late, and a system that captures immediately either breaks the commercial model or fails when the authorisation expires. Separate them from the first design.
A flight plus a hotel is sold without anyone establishing that this makes you an organiser with insolvency and refund duties. Determine package status in discovery, per combination, in writing.
Every supplier and channel has a test environment and a sign-off, and those weeks are nobody's to accelerate. Put each certification on the plan as its own dependency rather than as part of the integration task.
The honest answer is usually the third one, and on this vertical the honest answer is more often than elsewhere that you should buy. We are not an IATA accreditation body and we are not your consumer law adviser, so those judgements sit outside this table.
| Component | Our recommendation | Our honest verdict |
|---|---|---|
| Channel management and distribution plumbing | Buy | Connecting to dozens of OTAs and keeping each certification current is a commodity with a permanent maintenance cost. Building it yourself means owning every channel's retry quirks forever for no differentiation. |
| Inventory, rates and the booking record | Build | This is where your commercial model lives, and it is the part every packaged system models for the average operator rather than for you. It is also the layer that decides whether anything else can be trusted. |
| Payments and refund execution | Buy the core, build the edge | Buy the gateway and the card handling, which carry real compliance overhead. Build the entitlement calculation, because the policy is yours and no provider can compute it for you. |
Transparency
Every competitor publishes a total with no hours behind it. Here is the rate, the hours and the multiplication, so you can argue with any line. The scope priced here is a direct-sell operator with channel distribution. The drivers are: How many supplier or channel connections, Complexity of the rate model, Look-to-book ratio, Whether you sell packages and Payment timing.
Phase one range
$63,200 to $158,000
The 1,580 hour worked example at the ends of the rate band, about $102,700 at a $65 blend.
Typical timeline
3 to 5 months
Plus supplier certification weeks that nobody bills and nobody can accelerate.
Useful hours
1,170 to 2,280
Every module at its minimum, through to every module at its maximum.
| Driver | Hours |
|---|---|
| How many supplier or channel connectionsThe second is expensive because it forces the abstraction. The fifth is cheap because the abstraction exists. Certification is separate and is calendar rather than hours. | 80 to 200 each |
| Complexity of the rate modelSeasonal rates, minimum stays, occupancy pricing, promotions and corporate agreements compound. A single flat rate per unit is a different project from a real revenue model. | High impact |
| Look-to-book ratioA high ratio makes caching a commercial necessity and a correctness risk at the same time, which is where the availability engineering goes. | Drives the cache work |
| Whether you sell packagesComponent-level supplier terms, combined liability and insolvency protection are not a feature on top of single-item selling; they change the booking model. | Adds real scope |
| Payment timingDeposits, balance dates, authorisation held for weeks and partial refunds. Straight capture at booking is far simpler and far less common in travel. | 140 to 280 |
| Number of jurisdictionsThe first consumer-protection regime is a build, each additional one is an adapter, provided the policy layer was kept out of the booking path. | Medium |
| Migration of live bookingsYou cannot pause selling to migrate. Forward bookings have to move without losing their terms, which is a reconciliation exercise as much as a data one. | Rarely small |
| Supplier certification calendarEach channel's test environment and sign-off consumes weeks that nobody bills. They change your launch date rather than your price. | Schedule, not hours |
| Module | Hours |
|---|---|
| Discovery and channel inventory | 60 to 120 |
| Inventory and availability model | 180 to 340 |
| Rate plans and pricing rules | 160 to 300 |
| Booking and order record | 200 to 380 |
| Supplier and channel integration | 180 to 360 |
| Payments, deposits and capture | 140 to 280 |
| Changes, cancellations and refunds | 150 to 300 |
| Reconciliation and reporting | 100 to 200 |
Engagement
Four models for travel software development, each with the downside stated in the same breath. Those four are: Distribution and rate audit, Phase one build, Build and carry through certification and Ongoing engineering. Pick by how settled the scope actually is, not by preference.
Upside
Two to three weeks establishing where availability actually lives, how many channels contradict it, and whether your rate model can be expressed as data. It frequently removes scope.
Downside
You pay for a document, and on this vertical it quite often concludes that a channel manager you already licence covers most of the ask. That is a good outcome and a small invoice for us.
Upside
The eight modules above against a written scope, ending with one authoritative inventory, editable rates and a refund path that computes rather than interprets.
Downside
It is a selling foundation, not a full travel platform. Loyalty, dynamic packaging and mobile are later phases and saying otherwise would be a worse trade for you than saying so now.
Upside
We stay through supplier and channel sign-off, which is when integration assumptions get tested by somebody who is not us.
Downside
It ties our team to other people's test calendars, and those are not ours to speed up however much either of us would like.
Upside
A standing allocation, which suits an operator adding channels, markets or product types steadily.
Downside
It works when there is a genuine backlog and quietly wastes money when there is not. We will tell you when there is not.
Delivery
Five phases, each named by the artifact it produces rather than by a stage in a generic waterfall. Those phases are: Distribution map, Inventory model, Rate engine, Order and servicing and Channel certification. Each is named by the artifact it hands you, so you can ask to see one.
Phase 01
Every channel, what it can accept, what it sends back, and where availability is authoritative today. This artifact decides the shape of everything after it and usually surprises the operator.
Phase 02
Inventory, availability and offers separated on paper, with hold semantics and their timeouts agreed before anything is built against them.
Phase 03
Rate plans as editable data with a safe editor, and both the rule and the resulting price stored against every booking.
Phase 04
A booking record that absorbs a supplier schedule change without losing history, with the refund entitlement computed from the policy in force at sale.
Phase 05
Each connection taken through its own test environment and sign-off, tracked as its own dependency rather than folded into an integration ticket.
Non-functional
Copy this and run it against us, or against anyone else quoting for travel software development. Three groups cover: Correctness under concurrency, Idempotency and reconciliation and Evidence at the moment of sale. Copy any line straight into your own requirements document.
One authoritative inventory with availability derived from it, holds that expire on their own, and a documented answer on what happens when two customers reach the last unit at the same moment. Overbooking allowed only where the business chose it.
Every channel handler idempotent on the channel's own reference, because duplicates are certain rather than possible. A daily reconciliation that names discrepancies rather than absorbing them, with an owner for the exception queue.
The offer, the rate rule and the cancellation policy version all stored against the booking, because a dispute two years later is judged against the terms in force then. Card data never resident in your systems, with authorisation and capture separated.
Usually not, and on this vertical we say that more often than on any other. Connecting to dozens of OTAs and keeping each certification current is commodity work with a permanent maintenance cost. What operators actually lack is an authoritative inventory and a rate model they can edit. We would rather integrate with the channel manager you already pay for.
Hours times $40 to $100 per hour by role. The module table gives the range for each of the eight modules and the worked example shows 1,580 hours coming to about $102,700 at a $65 blend. Loyalty, dynamic packaging, mobile and any accreditation fee are excluded and named as excluded. We do not quote before discovery.
You do. The code is yours on delivery, booking and customer data live in your infrastructure rather than ours, and the channel integrations are yours to keep running or hand to another supplier. We do not retain a copy of your booking data.
New Distribution Capability is IATA's XML standard for exchanging Offers and Orders directly rather than through legacy messaging, and ONE Order collapses the passenger name record, the e-ticket and the miscellaneous documents into a single Order. IATA's aspiration is that the capability exists industry-wide by 2030, with most carriers moving around 2028 to 2029. The practical answer is to build a record that is order-shaped now and keep speaking legacy alongside it, because both will be live for years.
If you combine a flight with a hotel or a transfer for EU travellers, very likely. The revision became Directive (EU) 2026/1024 on 29 April 2026 with 28 months to transpose, so national law lands around September 2028. The concrete build items are that a voucher can never be forced, the traveller must be told they may take cash instead, and a supplier who cancels must refund the organiser within seven days.
By making one inventory authoritative and deriving availability from it with holds applied, rather than letting each channel keep its own copy. Most overselling we inherit comes from a stale cache that nobody chose deliberately, rather than from a race condition.
Yes, and it is the reason payment work is heavier here than in retail. Travel authorises early and captures late, sometimes weeks later, so authorisation and capture have to be separate from the first design and expiry has to be handled rather than discovered.
We do not have one, and we would rather say so than stretch an unrelated project to fit. Everything on this page is distribution mechanics, regulation and failure modes, all of which you can verify independently of us. Judge it on whether it describes your problem accurately, and ask us hard questions on the call.
Yes, and it is rarely small. You cannot pause selling to migrate, so forward bookings have to move with their terms intact while new ones keep arriving. We treat it as a reconciliation exercise with a rollback plan rather than a data load.
Longer than the integration, frequently. Each channel and supplier has its own test environment and sign-off, and the calendar belongs to them. We put each one on the plan as its own dependency so a slip is visible early rather than discovered at launch.
Four steps with a shape attached to each, so booking a call is a known quantity.
Bring your channel list, your rate plan structure, and the last time you oversold. Those three size the project faster than an hour of description.
We establish where availability is authoritative today and how many systems hold a copy. The answer usually explains every symptom you called about.
The modules, the hour ranges and the arithmetic, with certification weeks shown as calendar rather than cost. If your existing channel manager covers most of it, the document says that.
With the scope in hand you choose whether we build it, your team does, or your incumbent extends. The document is useful in all three cases and it is yours either way.
Almost every question on this page resolves to whether one system is authoritative about what you can sell. We will establish that, tell you which regulations bind you, and give you the hours either way.
Real feedback from the people we've proudly partnered with.
Sales Director |Cintas
United States
Zyneto Global Technologies provided excellent project management and technical expertise throughout the engagement. The team was responsive, collaborative, and adaptive, ensuring the project met our expectations and set a strong foundation for future growth.
Founder & CEO |Moneteo
We engaged Zyneto to design and develop a custom web platform for Moneteo, aimed at improving project management, data tracking, and collaboration across internal teams and external partners. Their work included full-stack web development, custom modules for workflow automation, API integration, and comprehensive testing.
CEO |E-Commerce Platform
Overall, their responsiveness and timely deliveries contributed positively to the project's success. The client achieved better data management and quality. The service provider delivered the project on time and ensured prompt responsiveness throughout the engagement. Their innovative approach was outstanding.
Explore further
Inventory, holds and the booking record
Search, checkout and the agent console
Traveller and on-property apps
Demand forecasting and rate recommendation
Servicing and change requests without a queue
If what you need is the F&B ordering product
Restaurants, kitchens and the hotel food line
Property, tenancy and the asset behind a stay
Every sector we build for, in one place
Forecasting, automation and assistant work that applies directly to booking and distribution systems.
