Publishing travel packages 60x faster
Role: Software Engineer
Client: Large travel organisation
Stack: Node.js and TypeScript (validation module), Next.js (frontend for the prototype), Firebase (caching results)
Context
Curated packages are hand-crafted travel experiences built by travel consultants. Each one bundles flights, stays and activities into a fixed duration, and is sold at a discounted price for the whole bundle.
I was a software engineer on the team that maintains the website that displays these packages.
When a package is built, its data comes from two sources:
Package information: pricing, flights, hotel details and other inclusions.
A CMS: images, marketing descriptions and similar content.
We combined the two into our own schema and cached the result in Elasticsearch for performance. Before a package could be published, it was checked by hand.
The problem
Publishing was slow and easy to get wrong, because the checking was manual.
Slow. Checking a package for missing information, invalid content and business-logic issues took about 30 minutes when the data was good. When it wasn't, it could take days. The manual process reported only one validation error at a time, so developers and consultants went back and forth, fixing one error at a time.
Error-prone. Spotting invalid data needed human eyes, so it was easy to miss things.
What I did
I made three decisions. Each one is what I chose and why.
Decision 1: Automate the validation step
What I chose: I focused on the validation step and automated it, rather than the rest of the publishing process.
Why: That was where the bottleneck was. Pulling the data together wasn't the slow part. The manual checking and the back-and-forth around it were.
Decision 2: Report everything that's wrong in one pass
What I chose: The tool pulls the package data and runs it through a series of rules that check for invalid information and for business-logic problems. It reports every issue it finds, not just the first.
Why: Reporting one error at a time was what turned a 30-minute task into days of back-and-forth. Explicit rules also don't miss things the way tired eyes do.
Decision 3: Prove it with a working prototype
What I chose: Over a weekend, I built an initial prototype of the tool instead of proposing it.
Why: A working tool is more convincing than a proposal, and a weekend was enough to try the idea on real packages.
Outcome: The core module that runs the validation was later integrated into the publishing platform that travel consultants use today.
Results
Publishing a package went from about 30 minutes to about 30 seconds, because the tool reports everything that's wrong in a single run.
Consultants and developers no longer had to work through problems one at a time.
The validation module I prototyped became the core of the publishing platform consultants use today.
| Measure | Before | After |
|---|---|---|
| Publish time | ~30 minutes if the data was good, days if not | ~30 seconds |
| Errors reported | One at a time | Everything in a single run |
| How checks were done | Manually, by human eyes | Automated rules for data and business logic |
| Status | Manual process | Core validation module in the publishing platform |
What I could do better
I'd consult my technical lead before building a weekend project. The prototype derailed some of the roadmap my lead had planned. It also fast-tracked the package publishing platform, which was a good outcome, but I'd rather have had that conversation first, so the work fitted into the plan instead of disrupting it.