What Shipping AncientTravel Taught Me About Building Systems

By Omar 3 min read

It took me two false starts to get AncientTravel into production. That’s not something you’ll see in our roadmap slide. But when people ask why the system holds up under user load today—even with these frankly exotic vendor APIs in the mix—it’s because we lived through those early failures.

Whenever we—meaning me and Dani, mostly—debated the “right” abstractions, the urge was always to reach for generality: “let’s solve this for future integrations,” “maybe just an event bus here for flexibility,” etc. It’s seductive, but inertia sets in fast. What we found, and what’s still visible if you grep this repo, is that systems aren’t durable because they’re abstract. They hold because they encode real, lived judgment about where entropy most threatens you.

One practical example from last week: to accommodate a surprise rate-limiting change from the Wasari booking API, I bypassed our shiny, future-proofed “provider adapter” and wrote a crude, dead-simple retry mechanism. Not only did it fix the user pain faster, it actually reduced the number of codepaths we needed to reason about. It’s tempting to think this will backfire later—but in the trenches, local optimizations often are global ones, if you’re careful what you accumulate.

Here’s an internal observation I didn’t anticipate: the single biggest source of velocity for us hasn’t been our choice of tech stack (though the Rust/TypeScript split paid off), but ruthlessly scoping the workflows before slotting in infrastructure. I re-learned this when our integration test suite ballooned to unmaintainable size—until we cut it down to the crude, painful essentials, the tests added more confusion than confidence.

Tradeoff: we still accumulate “debt,” but it’s the kind you can pay back without formal ceremonies. My admitted uncertainty: I can’t predict exactly how this “just-in-time correction” strategy will age if AncientTravel becomes a 10-person team, or if we have to support a second major destination provider. I suspect, but can’t rigorously prove, that it’ll still beat the “build the final system at the start” approach.

Here’s a falsifiable claim: if you can’t confidently delete or bypass part of a system today, it probably isn’t pulling its weight for your actual operation under current constraints.

My specific prediction, based on how our support metrics have moved since last Thursday’s deploy: the teams that can accept living with rough-walled, evolving systems (rather than ornate, fragile ones) will not only ship faster but also sleep better when the inevitable external surprises land.

The tension: too much tactical adaptation, you get spaghetti; too much up-front architecture, you get fossilized. For us, shipping AncientTravel was the proof that it’s possible to align system boundaries with actual fault-lines, not imagined futures—and the courage, this time, was in shipping before it was pretty.