Picking a Travel Tech Build Partner: What AU Operators Miss

Most tour operators who end up with software that doesn't work didn't pick a bad agency — they picked the wrong way. They chose based on hourly rate, a portfolio of slick-looking apps, and a founder who seemed switched on in the first call. Six months later they're chasing bug fixes on a booking flow that can't handle a split deposit, and their dev partner has never heard of a channel manager.

Choosing a travel tech build partner in Australia is a smaller market problem than it sounds. The pool of agencies who've actually shipped reservation software — not just "booking forms" but real inventory-aware, channel-connected, payment-splitting booking engines — is genuinely thin. That makes the question harder, not easier.

The first thing to test isn't their tech stack

It's their ops vocabulary. Before you talk about frameworks or timelines, describe your most awkward booking scenario out loud. Something like: "We take a 30% deposit at booking, collect the balance 14 days out, and if a guest cancels inside 7 days they lose the deposit but we refund the balance minus a $25 admin fee — and this varies by product type."

Watch what happens. A partner who's built travel software before will start asking clarifying questions: does the admin fee apply to group bookings per-head or per-booking? What triggers the balance collection — a scheduled job or a manual run? Does your current system handle the refund calc automatically or does someone work it out in a spreadsheet?

A partner who hasn't will say "yep, we can build that" and move on. That's the tell.

The same test works for channel sync. Describe your OTA connections — or the ones you want — and ask how they'd architect availability updates. If they talk about webhooks vs polling, rate limits and conflict resolution, they've been here before. If they talk about "API integrations" in the abstract, they haven't. You can cross-reference this against what actually breaks when you connect tour inventory to resellers — it's a useful checklist to bring into that conversation.

Portfolio questions that actually matter

Don't ask "have you worked with travel clients?" Ask:

• "Can you show me a booking flow you built with deposit and balance logic?"
• "Have you connected a system to Rezdy, Fareharbor or an OTA like Viator — and what broke?"
• "How did you handle timezone-aware availability for a multi-location operator?"

If the answer to any of these is "we haven't done exactly that, but we've done similar" — that's fine, provided they can describe the adjacent problem in detail. What you're screening for is pattern recognition. A dev team that built a membership subscription platform with complex billing rules has more transferable knowledge than one that built a generic e-commerce site with a checkout page.

Ask to speak to a past travel client directly. Not for a reference call arranged by the agency — just ask for a name and reach out yourself. Any partner worth working with will say yes.

The spec problem: why most projects go wrong before they start

The single most common failure mode in Australian travel tech builds isn't bad code. It's an underspecified brief that a well-meaning agency quoted against, built to, and delivered — and then the operator discovered the spec didn't capture half of what they actually needed.

This is partly the operator's fault and partly the partner's. A good partner's job is to find the gaps in your thinking before they quote, not after. They should be running a discovery phase — even a short one — that maps your actual booking rules, your current tools, your edge cases, and your reporting needs.

If a partner quotes you a fixed price off a two-page brief, be cautious. Either they've done this so many times they can fill the gaps themselves (possible, rare), or they're quoting a simplified version of what you actually need and will charge variations later (common).

Ask directly: "How do you handle scope that wasn't captured in the brief?" The answer should involve a process — discovery workshops, iteration budgets, or defined change-request pricing — not reassurance.

What "travel tech experience" actually means

In a market as small as Australia's, plenty of agencies will list tour operators or accommodation providers in their portfolio. But there's a wide range between:

• Building a contact form and calendar embed for a small activity operator
• Building a reservation system with inventory, channel sync, automated messaging and payment splits

The first is a website job. The second is a product build. They require completely different teams, different processes and different ongoing relationships.

If you're building something that will become the operational core of your business — where your staff take bookings, your guests self-serve, and your OTA connections live — you need a partner who has shipped software at that level. Anything less and you're paying them to learn on your project.

Reservation software for day tours breaks down the point at which off-the-shelf options stop fitting, which is usually also the point at which a build conversation starts. If you're not past that threshold yet, you might not need a build partner at all.

Pricing structures and what they signal

Three common models you'll see from Australian agencies:

Fixed-price project. Works when the scope is genuinely tight and both parties understand it. Rarely true for first-time travel builds. Fixed price often means the agency absorbs risk by cutting scope when problems arise.

Time and materials. More honest for complex builds, but requires the operator to be involved enough to catch drift. Good partners on T&M will give you a weekly burn summary and flag scope creep before it compounds.

Retainer/product team. A dedicated team working on your product month to month. Makes sense once you're past launch and into iteration. The right model for operators who've decided this is a long-term product investment, not a one-off build.

None of these is wrong. The question is whether the model fits the maturity of the project. A first build on T&M with a discovery phase is a reasonable starting point. A fixed-price quote on a spec that hasn't been tested against your actual ops is a red flag.

The ongoing relationship question

Custom travel software isn't a project — it's a product. The operator who treats it as a project (defined scope, delivery, done) usually ends up back in the market for a new partner within 18 months because the system has calcified and the original team has moved on.

Ask your prospective partner: "What does the relationship look like after launch?" You want to hear something about a support retainer, a handover process if you want to take code in-house, documentation standards, and how they handle urgent bugs versus routine improvement cycles.

If they talk about "hypercare periods" and then trail off, that's a project mindset. If they talk about how most of their clients are still with them two years post-launch and describe what they work on together, that's a product mindset. You want the second.

The same logic applies to your booking engine setup. Tour booking payment flows tend to evolve — new products, new refund rules, seasonal deposit changes — and you want a partner who can turn those around in days, not a new statement of work.

The shortlist

By the time you're evaluating two or three partners seriously, you should have answers to:

• Can they describe your ops back to you after one call?
• Do they have a live example of booking logic at your level of complexity?
• Have they connected to the OTAs or channel tools you use?
• How do they handle scope that wasn't in the brief?
• What does the post-launch relationship look like, and what does it cost?
• Will they let you speak to a past travel client without the agency in the room?

Price matters, but it's the last thing to compare — not the first. Two partners at similar cost can be wildly different in what they'll actually deliver. The ops vocabulary test, the edge-case questions, and the reference call will tell you more than any proposal document.