How to Choose a Travel Software Development Company

Arbisoft Editorial TeamPosted on September 2, 2026

20-21 Min Read TimeAdd as preferred on Google

Most guides on this question give you the same three instructions. Demand proof. Ask for a live booking platform instead of a mockup. Talk to past clients.

All three are worth doing and none will tell your shortlist apart, which is the problem you might eventually run into. By the time a buyer reaches us they have had three or four vendor calls and every one went fine. Nobody failed a question, so the decision gets made on price, and the buyer knows that is a poor way to spend two hundred thousand dollars.

This is the fact that reorganises it.

Your vendor's engagement ends at launch. The obligations they pick for you do not.

A handful of decisions made in the first weeks become permanent, and they arrive as sensible technical choices inside a document you skim on a Thursday.

• Payment architecture sets which PCI DSS self-assessment questionnaire you file every year, and how big it is.
• Caching design sets what every search costs in supplier fees, and whether suppliers throttle you.
• The intellectual property schedule sets whether you can move the code, and whether you may run what you own.
• The staffing clause sets your recourse when the engineers from the pitch become other people.

You would carry these obligations whoever built your platform. Your vendor only decides how heavy each one gets. Nobody warns you for two reasons.

1. Nobody is thinking about it during the pitch. An agency's senior engineers spend their time winning work, so the people who will make your early choices are not in the room while you are being sold to.
2. You cannot check what matters. Anyone can open a booking site and confirm it takes reservations. Nobody outside can see its cache hit ratio, or who legally owns the supplier adapters. The visible parts are the easy parts to make look good.

Arbisoft has been building softwares since 2007 and has worked on the KAYAK account since 2008. That is long enough to know which early decisions turn out to matter. One question runs through everything below: who is carrying this in year three?

Four Types of Travel Software Buyer, and Which Vetting Criteria Matter for Each

"Best" describes a fit between firm and product, and four products hide under this search. A team excelling at multi-supplier aggregation can be poor at a hotel group's direct site, where the work is conversion engineering against one supplier and none of the aggregation skill transfers.

Going direct, your obligations are lighter than this article implies, and we would rather say so than inflate them.

Building an agent portal, you have a four-second test:

If the demo has no credit-limit screen, they have not built one of these.

That screen never appears in a case study and no engineer builds it on spec. It exists because a real agency asked, then argued about pending bookings three times.

Custom Travel Software vs White Label: Should You Hire a Travel Portal Development Company at All?

A development company will never put this to you, so we will. For a real share of people searching this, custom development is the wrong purchase. A white-label platform goes live in weeks rather than months and handles branding, markups, payment gateways and switching modules on and off, at the cost of dependence on the provider's roadmap and a shared platform where differentiation is off the table.

The test: name the thing you need that no existing platform does.

A one-sentence answer means build. If the answer wanders, you may spend six figures rebuilding something available on a monthly licence. We would rather you licensed a platform now and came back in three years having outgrown it.

Two Eligibility Gates to Settle Before Evaluating Any Travel Software Vendor

Gate 1: GDS Integration and IATA Accreditation, or Are You Eligible to Sell What You Plan to Sell?

Every guide tests whether a vendor can handle GDS integration. The question above asks whether your business is permitted to do what your platform implies. Technical access to a global distribution system is one question; authority to issue tickets and settle with airlines is another, and it is the one that gates you.

What accreditation actually gets you. IATA accreditation gives you a code and Billing and Settlement Plan access; in the US you need ARC accreditation, and an IATAN air-ticketing application requires proof of ARC first. Without it you ticket through a host agency or consolidator on their credentials.

Timelines. Requirements vary by country, and a direct application runs four to six weeks. Vendor-published certification figures then run two to six weeks for standard scope and two to four months with custom workflows, which are directional at best, since the firms publishing them sell the work.

The red flag is any version of "we'll handle the GDS side." That is not a plan and it is not theirs to handle.

Two vocabulary tests. A vendor claiming to be "NDC certified" is working from old information, since IATA retired those New Distribution Capability levels in 2022 for the Airline Retailing Maturity index. And ask what happens when a supplier hands them EDIFACT rather than REST. Some still will, cheerfully, in 2026.

Gate 2: Booking Seasonality, or Which Booking Window Are You Launching Into?

Travel carries a seasonality most software does not, and almost no vendor treats it as an engineering constraint. Wave Season is the clearest case: the cruise industry's peak booking period, January through March, when lines release their most aggressive annual promotions.

Ask what the last date is at which a slip becomes a lost year, and what the contract says if it moves. A four-week slip in most software gets absorbed. The same slip on the wrong side of your booking window costs the year, and good engineering afterwards will not buy it back.

Obligation One: PCI DSS Compliance Scope for a Travel Booking Platform

PCI DSS compliance is mandatory for anyone taking cards. The expensive variable is scope, meaning which self-assessment questionnaire your architecture requires. That architecture determines scope is not our insight. What nobody mentions is who decides.

You are not the architect here. Your vendor is, in week two, before you know a decision is on the table.

The Three PCI Compliance Tiers a Travel Platform Lands In

Your vendor picks the exam. You sit it every year, and they are not in the building.

An iframe can qualify for SAQ A, which surprises people who assume anything embedded pushes them up, and segmentation can pull scope back down. Merchant level is a second axis, set by transaction volume, and a confirmed breach moves any merchant straight to Level 1 with a forensic investigation, whatever their size.

Why Travel Software Lands in SAQ D More Often Than Ordinary E-Commerce

A standard published example of an SAQ D merchant is a business taking payments across web, phone and in person, and travel does all three.

• Phone and manual bookings, high value and under time pressure, which is how a careful architecture gets defeated by someone reading a card number aloud.
• Card details held to pay a fare once the passenger name record is ready, which is storage whatever it gets called internally.
• The service fee charged outside the main flow when a merchant of record caps your commission.
• Agent-owned cards in B2B portals.

Each is a legitimate business requirement, and each moves you a tier if handled without thought.

The 2025 PCI DSS Change That Catches Travel Buyers Out

One 2025 change catches people. From 31 March, merchants embedding a processor's payment form must confirm their site is not susceptible to script attacks to stay eligible for SAQ A, and redirects sit outside it. The detail people misread: that confirmation covers your whole site, so a marketing team adding a chat widget has become a compliance event.

PCI and Merchant of Record Questions to Ask a Travel Software Vendor

Ask which SAQ the platform puts you in and what in the design puts you there. Then where a full card number ever exists, even in memory. Then how you take a phone booking without dropping into SAQ D, the question separating firms who have built for travel from firms who have built e-commerce.

A strong answer sounds mechanical and slightly boring: hosted fields or a redirect, a named tokenisation vault, whether the service-fee flow touches a full card number.

Ask who the merchant of record is, too, since the merchant of record is the legal entity collecting money from the traveller and therefore decides who owns refunds, chargebacks and tax liability. That party is often the one capping your commission, which is what produces the service-fee workaround above.

Obligation Two: Look-to-Book Ratios, or What Every Search Costs You Forever

Look-to-book is the number of search requests a platform sends suppliers per booking. You pay for the searches whether or not anyone books. This is the obligation missing from vendor selection, and it may be the most expensive item here.

A single calendar shopping request covering one month can generate roughly 450 API calls as the system works through date combinations, per OAG's analysis. Nobody booked anything. You were still billed 450 times.

How Look-to-Book Ratios Grew, by Era

OAG is explicit that these are estimates triangulated from independent sources rather than measurements. Fan-out compounds them, since one metasearch query may reach fifteen OTAs, each drawing on its own suppliers. Supplier access is also governed by these ratios, so your own suppliers rate-limit you for the offence of having traffic that converts poorly.

A vendor who has never thought about this builds a platform whose unit economics break when it starts working, and it stays invisible in a demo for a reason that is almost funny: a demo has one user in it. Everything in a demo is cheap.

Travel Caching Strategy: The Trade-Off They Should Explain Unprompted

Cache aggressively for speed and cost and you risk showing a price that is not real. Cache conservatively for accuracy and every search runs slow and expensive. A good vendor states the principle before you ask: a stale price on a landing page is fine, on the results page it is not.

A price on a landing page is a billboard. A price on the results page is a handshake.

Skyscanner's partner documentation is the clearest public evidence. Their results-page cache varies by departure proximity and partners can adjust it. Their booking panel cache sits at 10 minutes and cannot be modified. They will negotiate cache duration right up to the point where a traveller is looking at a specific bookable price, and then the conversation stops.

The Cache-to-Cache Problem No Travel Software Vendor Can Fix

IATA's October 2025 look-to-book white paper, drawn from research with 14 airlines, 11 IT providers and 8 sellers, adds the part no vendor can fix. Every layer of the distribution stack caches, none of them talk to each other, so stale prices at one layer pollute the next. It also finds caching works best on standard filed fares and struggles with dynamic pricing and bundles, which means the modernisation the industry spent five years on is the same force making caching less effective.

A vendor who explains where their responsibility ends has read this instead of the one who guarantees price accuracy.

Four Search Performance Numbers to Request From Any Travel Software Company

Ask for four numbers from the last build:

1. Cache hit ratio
2. P95 search latency
3. Price accuracy
4. Supplier request cost per booking

A firm that did the work has these somewhere, possibly in a Slack thread from eighteen months ago. A firm that did not will talk about page-load speed, which is a real subject and a different one.

Why AI Booking Agents Changed Travel Search Economics in 2026

Agents do not get tired and have no time zones, so the off-peak baseline becomes the operating floor, and Amadeus and Sabre both project up to 200,000 searches per ticket. Sabre's February 2026 cache-powered shopping reports up to 28 percent look-to-book reduction, though OAG notes these products are early-stage and neither is believed to cover airline.com fares, where dynamic pricing is most common. The part most resistant to caching is the part they do not reach.

Ask how the architecture changes if a meaningful share of your traffic is agents next year. Most firms will not have an answer, which is not disqualifying, so treat specificity as a bonus signal.

Obligation Three: Code Ownership and IP in Travel Software Development Contracts

Every guide says make sure you own the code. Every vendor says you do. Specialist legal writing covers this better than a software company will, so start with the part it does not know.

Why Code Ownership Works Differently in Travel Software

Travel vendors reuse booking-engine cores and supplier adapters across clients. That is normal, and Arbisoft does it too. It also means the boundary between what a vendor built for you and what they already owned runs through the most valuable parts of your platform.

An unlisted carve-out is where a white-label product hides inside something sold as custom.

So the first ask is procedural: send me the background-IP schedule. If none exists, you have your finding.

Four Things Underneath "You Own the Code"

Background IP is what the vendor owned beforehand; foreground IP is what they built for you, and vendors legitimately keep the former. Four things then matter.

1. Is background IP listed in a named schedule rather than a clause gesturing at the category.
2. How assignment works, which should be present-tense with a further-assurances covenant, since work-made-for-hire applies only to certain enumerated categories and reaches copyright without touching patents.
3. Whether the chain reaches whoever typed the code, since a vendor can only assign what it holds.
4. What triggers assignment, where final project payment is reasonable and "settlement of all sums" leaves ownership hostage to a support invoice three years later.

The Licence Clause Most Travel Software Buyers Never Ask For

Then the clause most buyers never ask for, missing from the earlier version of this page too. Owning code and being able to run it are two different rights. If your platform embeds the vendor's background IP, and it will, ownership of the foreground work is worth little without a licence covering the embedded parts.

Ask for a perpetual, irrevocable, transferable licence back to embedded background IP that survives termination, plus repository access and exit assistance. Walk away from a deliverable you own and cannot operate.

We are engineers rather than lawyers, so hand this list to your solicitor. Thirty minutes of review returns more here than anywhere else in the purchase. Our own bias is on the record: we lean on open source partly because it avoids lock-in and lets clients deploy on their own infrastructure. If a vendor pauses when asked whether you can run the platform without them, the pause is the answer.

Team Continuity: Will the Travel Software Team You Met Be the Team You Get?

Arbisoft has more than 700 people, which makes us the kind of firm this question exists for. Everyone knows the pattern: seniors in the pitch, juniors on the project. Asking for named team members is fine and insufficient, since names can be swapped after signature without anyone breaking a rule.

What nobody tells buyers to check is whether they hold contractual recourse.

A client can review the developers on their account, conclude several are not up to the work, request removals, and find the agreement gives them no mechanism to compel one.

So ask what the contract says about your right to request removal and about notice before substitution. Then ask for continuity, meaning whether the same people are on an account years later. Arbisoft has been on KAYAK since 2008. Make any vendor evidence that rather than assert it, ours included.

10 Questions to Ask a Travel Software Development Company

How to Test a Travel Software Development Company: Run a Paid Pilot

Two to four weeks, paid at your normal rate, before the main contract.

Scope it as one supplier integration behind a normalised response schema, delivered with the adapter layer, instrumentation showing call volume and error rates, and a handover document written for someone who was not there.

What you are measuring:

• Did they obtain credentials themselves?
• What happened when the supplier's response did not match its own documentation?
• Can a second engineer add supplier two without asking questions?

Other guides suggest asking how a vendor would architect a multi-GDS search, and a prepared salesperson answers that beautifully. The pilot answers it with evidence.

One integration proves almost nothing. An architecture where the second supplier costs less than the first proves a great deal.

Travel Software Development Cost: How to Read a Quote

We are not publishing a cost table. We collected the ranges from vendors ranking for these terms and found $8,000 to $110,000 for the same nominal MVP, each calibrated so the publisher's pricing looks like the sensible middle. Ours would be too.

Two Things That Hold Up Better Than Totals

Maintenance escalates rather than sitting flat. The 15 to 25 percent of build cost everyone repeats comes entirely from development vendors, while Gartner's pattern runs 10 to 25 percent annually in years one and two and rises toward 20 to 40 percent by year six, so budget the year-five number.

The back office can cost as much as the customer-facing product. That second point is the most under-scoped part of a travel build. Travelliance runs a platform for airline crew and stranded passengers with a database of over 7 million users, and Arbisoft has kept it running long enough to see which parts earned their keep. The booking flow got the meeting time, because it is the part you can show people. The work that mattered commercially was accounting: invoicing airlines against every booking and letting them approve or dispute each invoice. No traveller has seen that screen. It is where revenue gets recognised, and if it breaks, the platform is still up and the company still is not getting paid.

If your quote treats the back office as phase two, you are being quoted for the part of the product that photographs well.

Four Checks to Run on Any Travel Software Quote

So check four things:

• Is the back office scoped and priced separately?
• Is each supplier integration itemised?
• Is compliance scope named with the work required to reach it?
• Is post-launch support a recurring line rather than a warm sentiment?

A quote missing all four gets completed later as change requests at a worse rate.

Travel Software Development FAQs

What is the difference between GDS and NDC?

A global distribution system is a network aggregating supplier content. New Distribution Capability is an IATA messaging standard for how airlines retail that content, supporting richer offers than legacy EDIFACT allows. You can integrate a GDS without NDC capability, and NDC support varies by GDS and by airline.

Do I need IATA accreditation to build a travel platform?

Not to build one. Accreditation gives you authority to issue air tickets and settle with airlines. Without it you ticket through a host agency or air consolidator on their credentials. Requirements vary by country.

How much does travel software development cost?

Published ranges are marketing artifacts, since we found $8,000 to $110,000 quoted for the same nominal MVP. Use the four quote checks above instead, and budget maintenance on an escalating basis rather than a flat percentage.

Who owns the code in a custom travel build?

You should, and the sentence carries no weight without a listed background-IP schedule, a present-tense assignment, subcontractor flow-down, an assignment trigger tied to final project payment, and a licence to the background IP embedded in your platform.

How can a travel software vendor's experience be verified?

Ask for cache hit ratio, P95 search latency, price accuracy and supplier request cost per booking from a previous build. A live URL proves a platform exists. Those numbers prove somebody engineered it.

Choosing a Travel Software Development Company: Making the Decision

Every criterion reduces to one question: who is carrying this in year three? Vendors leave at launch. The compliance filing, the supplier bill, the ownership terms and the codebase stay behind.

Score each vendor against the question table, weighted by which of the four buyers you are, then run the pilot.

Some results should point elsewhere. A Sabre-centric integration with no product build around it belongs with a Sabre Red App certified shop, who will beat us on price and speed. Fifty engineers on a legacy airline migration calls for an enterprise IT firm, and we are the wrong shape. A hesitant answer to the white-label test means licensing a platform and spending the money on distribution instead.

If the answer points at us, start a conversation and bring the question table. We would rather answer the hard version.