How a global travel marketplace unified partner contracts in 20+ languages

Client background and market position

The client is one of the largest online travel marketplaces in the world. It sells flights, accommodation, car rental, and insurance, all of it supplied by partner companies rather than owned in-house. Each partner contract sets the commissions, the rates, and the commercial terms, which makes the contract the point at which revenue is defined. Contract accuracy is therefore a financial control issue.

Finance and commercial teams handle these agreements daily and need one environment in which to draft, review, and approve them. The organization employs tens of thousands of people and applies the same standards to every internal system: a shared design system, a dedicated translation function, and a product owner with roughly fifteen years of history on the account. The platform was built from scratch to operate inside that framework.

Operational and technical challenges

• Contract complexity was the primary constraint. Dozens of contract types exist, each composed of multiple sections and clauses that reference one another. Building the platform meant first understanding how the client's financial and operational processes connect, because a misread clause dependency surfaces later as an incorrect commission or an invalid contract.

• Reviewers had no way to see what changed. A contract passes through several reviewers before it reaches final form, each adding, editing, or removing content in long documents. Identifying what actually changed between two versions meant reading them, which slowed approval cycles and created the risk that a change to a financial term would go unnoticed.

• Long contracts slowed the interface down. Contracts are long and densely structured, so displaying a full contract without the page becoming sluggish was the main engineering trade-off in the product. A slow internal tool loses its users, and the process drifts back to email and attachments.

• Independent delivery inside a shared enterprise shell. The application had to behave as one seamless part of a much larger internal product, alongside ten to fifteen sibling applications built by teams that do not interact, while shipping on its own release cycle and staying visually consistent with a design system it does not own.

• Localization was a hard requirement despite English-first usage. Employees work in English by default, but a globally distributed workforce meant the platform still had to ship in more than 20 languages, with translation handled by a separate internal team. Each round of new language files brings its own crop of layout and text-rendering defects.

The result is a purpose-built internal web platform covering the whole commercial relationship with each partner: the agreement, the rates and commissions attached to it, and the history held against every partner. It sits inside the client's shared internal environment, so staff open it from the same address as every other internal tool. Inside it, a contract is structured data rather than a document, created and populated section by section, routed through review, and issued as a PDF at the end. Contract types differ by partner category, so the structure had to support car rental prerequisites and the insurance contracts that depend on them, without duplicating the clauses the two share.

The interface is built in React with TypeScript and Redux, on top of the client's design system, extended with custom components where the shared library did not cover the product's requirements. The most significant feature is the comparison view: select two versions of a contract, and it displays every addition and deletion, in the same way a code diff does, so a reviewer assesses the change instead of rereading the document. Interface design was produced in Figma ahead of implementation by the same developer.

This is what was built against each of those constraints:

• A contract structure that mirrors the commercial process. Every contract type was modelled section by section, with the dependencies between clauses encoded so that related agreements stay consistent instead of relying on the person filling them in.

• A version comparison view. Two versions of the same contract are placed against each other with every addition and deletion marked, so a reviewer checks the change rather than the whole document.

• Rendering built for long contracts. The interface holds a full contract on screen without the page degrading, which is what keeps the tool in use instead of the process drifting back to email.

• An independent release path inside the shared environment. The application ships on its own schedule alongside ten to fifteen other internal applications, and custom components extend the client's design system so it still presents as part of one product.

• Interface design delivered with the build. Screens and components were designed in Figma before implementation, covering the design gap on a product with no assigned designer.

• A localization pipeline for more than 20 languages. All text sits outside the code as key and value pairs, ready for the client's translation team, with the returned language files integrated and their layout effects resolved.