A non-technical founder needed a working self-transfer product on one corridor, built so the list of corridors could grow without a rewrite. In this kind of engagement the first corridor is rarely the danger. The second one is, because the shortcut that ships the first corridor fastest is usually the thing that makes the second one expensive.
To a self-transfer engine, an airport is a bundle of rules about terminals, borders, bags and time.
On a map an airport is a code and a location. To a product that builds connections out of separate tickets, it carries much more. It has terminals, and some connections mean moving between them. It has a border, and some passengers have to cross it just to collect a bag. It has a minimum transfer buffer that reflects how long all of that really takes there. It is served by particular airlines, and it belongs to particular corridors where it makes sense as a stop between an origin and a destination. Each of those facts changes whether a connection through that airport can honestly be offered.
Those facts can live in one of two places. They can be written into the program, as conditions that say this airport needs a longer buffer or that one involves a terminal change. Or they can live in data, as entries in a catalogue that the engine reads. In the program, adding an airport means editing code, testing it and releasing it, with the risk that the edit breaks an airport that was already working. In data, it means adding an entry, and the engine, which already understands that kind of rule, applies it. The difference is invisible on launch day and decisive on every day after.
The other thing newcomers rarely expect is that flight data is not freely available. Live prices and schedules come from providers who decide who may connect, at what volume and on what commercial terms, and small operators are often turned away or priced out. For a new travel product, whether it can get the data at all is a larger risk than any engineering decision. That is why it is worth testing before anything else is built.
Whether the product can grow is settled by an architecture decision on day one. Airports and corridor rules live in data, so adding a city means adding a row. Left until later, the same decision turns into a rewrite, because by then the launch corridor is threaded through the whole application.
Early products usually break at their second market.
A first product is built to prove that one thing works, and under that pressure the specifics of the first market go straight into the code. The first city's quirks become conditions, its airports become constants, its rules become branches. It ships quickly and it works. Then the second market arrives, and every one of those shortcuts has to be found, generalised and retested, often by someone who did not write them.
The other early failure has nothing to do with code. A travel product depends on data it does not own. Teams build the interface, the engine and the brand, and then discover that the data they need is gated, expensive or simply not offered to a business of their size. Weeks of work end up resting on an assumption nobody tested.
The reflex, and the fix.
Hard-code the launch corridor
It ships the first corridor measurably faster, and the first corridor is the one being paid for.
Every later city becomes a code change, a deployment and a regression risk. Growth turns into engineering work, permanently.
Model airports and rules as data
More structure than the launch corridor needs, and a configuration surface to design before anything ships.
Eighty-eight airports at launch and no rewrites to expand the corridor set, because expansion is configuration.
Put the thing that will change into data. The launch corridor is the one certainty and the corridor list is the one variable.
A data-access test as the first milestone
Before any product work, confirm that the flight data can be obtained at all, on terms a small operator can accept. Flight data is gated, and for a small operator that is the risk that ends projects, so it is answered first and cheaply.
Airports and corridor rules as configuration
The catalogue that will grow lives in data. Transfer buffers, bag rules and corridor status are rows, which also keeps the viability rules in one place where they can be maintained, instead of scattered through the code.
Prove the engine on one corridor
The search and viability engine is validated on a single corridor, where its behaviour can be checked against what happens at real airports, before the catalogue widens.
Milestones a founder can see working
Delivery is staged so a non-technical founder watches each stage run, and never has to wait seven weeks to learn whether the whole thing holds.
What each choice cost, and what it bought.
ATesting data access before building anything
The first milestone produced no product at all. It answered one question: can this business get the flight data it needs, on terms it can accept. That is hard to present to a founder as progress, because there is nothing to click. It is also the risk most likely to end a small travel project outright, and finding that out after the interface and engine were built would have wasted all of them. Answered first, it was cheap. Answered last, it could have been fatal.
BPutting airports and rules in data from day one
The launch corridor did not need a configuration surface, and designing one added structure before anything shipped. Hard-coding would have been measurably faster for the first corridor, which was the one being paid for. The data model is what made the next corridors cheap: the product launched with 88 airports and has needed zero rewrites to expand. It also kept the viability rules in one place, where they can be read, checked and corrected without touching the engine.
CProving the engine on one corridor first
The engine was checked against reality on a single corridor before the catalogue was widened. That meant holding back the breadth that a founder naturally wants to show. In return, a wrong answer during validation could be traced to its source, the engine or an entry, and fixed in the right place. Once the engine was trusted, widening the catalogue was a data exercise, with each search evaluating 19 candidate airports drawn from it.
DDelivering in milestones a founder can see
Each stage of the seven weeks ended in something that ran and could be shown. That costs some efficiency, because every stage has to be finished enough to demonstrate. It buys a founder who can make decisions on evidence as the work goes, and who is never asked to trust a long stretch of invisible engineering that might or might not hold together at the end.
- Confirm the data can be obtainedthe risk that ends small travel projects, tested first
- Model airports and rules as datathe expansion decision, taken before launch
- Prove the engine on one corridorwhere answers can be checked against real airports
- Build the consumer surfaceeach stage shown working to the founder
- Widen by configurationnew airports as entries, not releases
A single headline number hides where a system fails. This work was scored on the dimensions that actually decide whether it holds in production, measured on real, held-out cases rather than the demo path.
Timeline, airport count, candidates per search and the rewrite count are measured on the delivered system.
A product that ships the launch corridor quickly, then needs an engineering ticket, a deployment and a regression pass for every new city.
A working self-transfer product delivered in seven weeks, covering 88 airports, evaluating 19 candidate airports per search, with zero rewrites required to expand the corridor set.
What it owns, and what it hands to a person.
Data-driven expansion covers airports and rules of the kind already built. A genuinely new itinerary type, such as a chain through several hubs in place of a single intermediate airport, is an engine change and is scoped as one. A corridor whose rules do not fit the existing rule types is flagged for the same reason. No configuration row can describe a kind of rule the engine does not understand.
A product that has to grow should put the thing that will change, the catalogue or the rules, into data, prove the engine on one narrow case, and then expand by configuration instead of by release.
To an engine that builds connections, an airport is a set of facts about terminals, borders, bags and transfer time, and those facts decide what can be offered.
Whatever will change after launch, such as the catalogue of places or the rules that apply to them, belongs in data the engine reads.
The decision that makes expansion cheap has to be taken before the first release. Taken afterwards, it costs a rewrite.
In travel, access to flight data is often the largest single risk in a project. Test it first, before any product work begins.
Prove an engine on one narrow case where its answers can be checked against reality, then widen by configuration.