A JavaScript Squad Inside a Business Travel Platform

Why a Travel Platform Brings In a Squad

TravelBank runs business travel and expense management for companies that want one place to book trips, control budgets and reconcile spending. For a product like that, hotel inventory is not a feature on a roadmap. It is the shelf. Every additional supplier means more properties, better rates in more cities, and fewer moments when a traveler leaves the platform to book somewhere else.

The difficulty is that adding a supplier is never a small project. It touches search, rates, room selection, price verification, payment and the record of the booking afterward, and every one of those steps handles a customer's money. It also competes for the same engineers who are shipping everything else the business has promised. In early 2020 TravelBank chose not to make that trade. It brought in an embedded squad from UDX to own one supplier integration from the first API call to a confirmed reservation.

One Supplier, End to End

The assignment was a major global hotel supplier, integrated into TravelBank's existing hotel search service so that its properties would appear alongside the inventory travelers already saw. Our engineers worked inside TravelBank's TypeScript and Node.js codebase, in its repositories, against its backlog. The work ran in the order a traveler experiences it.

How the Squad Worked

We call this model an integrated team, and the phrase is literal. The squad was not a vendor that received a specification and returned a deliverable. It joined TravelBank's daily standups, took its tickets from the same board as everyone else, and was accountable to the same engineering leadership.

• Dedicated senior engineers, not a rotating bench. The people who learned the codebase in the first weeks were the people who shipped the booking flow. Roadmap and technical debt had a named owner, and so did service and front-end development.
• Supporting specialists on request. Cloud and DevOps expertise stood behind the squad and was drawn in when the work called for it, instead of sitting on the engagement full time.
• Every piece of work tied to a ticket. Progress was visible in TravelBank's own tracker, in its own terms, without a separate status report to interpret.
• Environments that match production. Our standard is containerized development environments that replicate higher environments exactly, which removes a whole category of "it worked on my machine" surprises from an integration like this one.
• A deliberate onboarding. Time was set aside at the start to learn the stack and the domain properly. It is the least glamorous part of an engagement and the one that most determines how fast the rest goes.

When an Embedded Squad Fits, and When It Does Not

This model is a poor choice for work nobody has defined. If the question is still what to build, a squad will spend your money discovering that, and a short strategy engagement is a better first step. It is also the wrong tool for a permanent gap. If you will need these skills every quarter for the next three years, hire for them.

It fits when the work is well understood, bounded, and important enough that it should not wait, but not so central that your own team must be the one to do it. Supplier and partner integrations are the classic case. So are migrations, platform upgrades and compliance deadlines. In each, the cost of delay is real, the scope has edges, and your own engineers are more valuable on the product only they can build.

If you are weighing that decision now, the useful conversation is about scope and handover, not rates. What exactly would the squad own, how would it plug into your process, and what does your team keep when the engagement ends?