A Country Without a Domestic Airline
There is a version of this project that exists only in the imagination of a younger, more optimistic person. It involves standing on an apron somewhere, watching an ATR 72 power up its turboprops, and feeling the particular satisfaction of knowing you had something to do with that.
The actual project involved a great deal of spreadsheet logic, regulatory documents, cargo classification rules, and the surprisingly complex economics of a half-full hold on a short domestic route. The planes are extraordinary. They were not, in any meaningful sense, the point.
The brief came from a private investor, let's call him Vincent, who had identified something that looked, on the surface, like an obvious gap. Georgia, a country of roughly four million people, sits at a geographic crossroads that makes internal travel genuinely difficult. The three cities that matter commercially, Tbilisi, Kutaisi, and Batumi, are connected by roads that wind through mountain terrain and a rail network that is functional, cheap, and distinctly unhurried. A businessperson needing to be in Batumi for a morning meeting and back in Tbilisi the same evening had, in practical terms, no good options.
No scheduled domestic carrier existed. A small charter operator flew light aircraft out of a satellite airfield, but their model was closer to private aviation than commercial transport, limited routes, limited frequency, pricing that served occasional tourism rather than regular business travel. There was infrastructure. There were airports. There were passengers who needed to go somewhere. There was no airline.
Vincent's question was straightforward: could someone build one, and what would it cost and take? Our job was to find out, not by modelling a fantasy, but by working out every commercial, operational, and regulatory component in enough detail that the answer would be defensible, presentable, and true.
That meant understanding not just the opportunity, but everything that would shape and constrain it. Who was the real customer? Not tourists, business travellers, executives, consultants, people for whom reliability and time had a concrete value. What were they currently doing? Mostly taking trains, often overnight, sometimes leaving at 3am to arrive presentable. What would it take to change that behaviour? Not just a cheaper fare, a credibly better experience, reliably delivered.
The regulatory environment added its own texture. Georgia's civil aviation framework is real and functional, broadly aligned with international standards. But operating within it, obtaining route licences, managing certification requirements, navigating the relationship between official process and practical reality, required understanding that went well beyond reading the published rules.
None of that is visible from the apron. But all of it determines whether the plane ever gets there.
Designing What Doesn't Exist Yet
The word "product" in an airline context does a lot of quiet work. To a passenger it means a seat, possibly a meal, perhaps the ability to change a booking without paying a penalty. The actual product range of even a small domestic carrier is considerably more involved than that.
For this airline, the product design started from a simple principle: every revenue stream had to be architected deliberately, because nothing could be assumed. There was no legacy pricing to inherit, no existing fare structure to adapt, no historical booking data to lean on. Every product, every price point, every rule governing what a customer could buy, change, or combine, had to be reasoned from scratch.
For passengers, that meant building out a full fare family structure. Not just "economy" and "business" but the logic underneath them, what a flexible fare permits versus a restricted one, how seat selection is priced, what rebooking costs under which conditions, how upgrades are offered and at what margin. Each of these is a product with its own commercial logic, and they interact. A customer who books a restricted fare and then needs to change it is not just an inconvenience; they are a yield management decision.
Dynamic pricing sat at the centre of the passenger model. Early bookings received better fares; last-minute travel carried a premium. This is standard airline logic, but it needed to be designed explicitly for a market where the dominant alternative, the train, charged a flat, predictable fare regardless of when you booked. The pricing model had to reward planning without making the airline feel inaccessible to the spontaneous traveller. That balance required thought, not just a formula.
Cargo was a different discipline entirely, and one that quickly revealed itself as non-optional. The economics of short domestic routes with relatively modest passenger volumes meant that a passenger-only model would rarely produce a profitable flight. The fixed costs, ground handling, apron services, landing fees, crew, don't reduce because the cargo hold is empty. Cargo wasn't an add-on. It was the difference between a viable operation and an expensive one.
But cargo is not a single product. Consumer cargo, packages, personal shipments, same-day and next-day delivery, had one pricing and handling logic. Corporate cargo, with its bulk volumes, recurring schedules, and service level requirements, had another. And within both, a further layer of classification: ordinary goods versus restricted ones. Lithium batteries, flammable liquids, biological samples, compressed gases, these trigger entirely different workflows, different insurance requirements, different documentation obligations. In some cases, they cannot travel on passenger aircraft at all.
There was also the geometry problem. A cargo hold has two constraints simultaneously: weight and volume. A consignment of dense industrial components might hit the weight limit while leaving half the hold empty. A consignment of large, lightweight goods does the opposite. Profitability depended on loading efficiency, not just filling the plane but filling it well. That is a logistics problem, a pricing problem, and a systems problem all at once, and it required modelling before it could be managed.
By the end of this phase, the product range ran to dozens of distinct offerings across passenger and cargo lines, each with defined pricing logic, operational requirements, and revenue assumptions. None of it was complicated for its own sake. Every decision had a reason, and every reason had a number behind it.
The planes, to reiterate, were the easy part.
The System That Made It Real
At some point in a project like this, a business case stops being an intellectual exercise and becomes something a real person must look at, question, and ultimately trust with a significant amount of money. That transition, from analysis to artefact, is where a lot of otherwise solid work falls apart.
The conventional approach would have been to consolidate everything into a financial model, produce a presentation, and walk Vincent through it slide by slide. That approach has a well-known weakness: it shows a conclusion without showing the working. A sophisticated investor can accept the numbers on a slide, or they can push back on them. What they cannot do is interact with them, change an assumption, follow a revenue thread, see how a pricing decision ripples through to margin. A slide deck is a statement. It is not a system.
The decision to use Odoo Community Edition as the operational core of the business case was taken precisely because it collapsed the distance between the model and the thing being modelled. Odoo is a modular, open-source ERP, not airline software, not a bespoke solution, but a platform with deep, mature capabilities across product management, sales, accounting, and e-commerce. Configured correctly, it doesn't require you to build the infrastructure for those capabilities. You configure and populate what already exists.
That distinction matters more than it sounds. Building a product catalogue from scratch, in a bespoke system or a spreadsheet, is a development project. Building it in Odoo is a configuration exercise, and the result is a live, queryable, internally consistent data structure that every other part of the system can reference directly. The fare families, the cargo classifications, the ancillary products, the pricing rules, all of it existed as structured data, not as cells in a workbook that might or might not match the cells in a different workbook.
The CRM and sales pipeline became the demand model. Routes were treated as opportunities, progressing through stages that reflected the confidence level of the underlying assumptions. Expected revenue per route was calculated against the product mix, what proportion of passengers were expected to buy which fare type, what ancillary attach rate was assumed, what load factor the model required to break even. Changing an assumption updated the model in real time. When a co-investor asked a difficult question, the answer wasn't a promise to recalculate. It was a change to an input, visible immediately, traceable all the way through to the P&L.
The internal approvals and workflow functionality meant that the business case itself had a governance trail. Stakeholders reviewed, commented, and signed off within the system. The version that reached the final decision meeting was demonstrably the version that had been scrutinised at every prior stage. In a process involving multiple parties with different risk tolerances and different questions, that kind of auditability is not a minor administrative detail. It is the difference between a decision and an assumption.
But the most tangible expression of what Odoo made possible was the e-commerce front-end, and that belongs in the next section.
Section 4: An Airline You Could Actually Use, For Now
There is a particular moment in a client presentation when something shifts. It is the moment when the person across the table stops evaluating what they are being told and starts experiencing what they are being shown. For this project, that moment came when Vincent opened a browser and booked a flight.
Not a simulation. Not a wireframe with placeholder buttons and dummy text. A working e-commerce front-end, built on Odoo's native commerce capability, populated with the actual product range, the routes, the fare families, the ancillary options, the cargo services. He could select Tbilisi to Batumi, choose a fare tier, add a baggage allowance, select a seat, and proceed to checkout. The products he was looking at were the same products sitting in the catalogue that fed the demand model that produced the P&L. It was one system, end to end, and it answered, concretely, the question that no spreadsheet can fully answer: does this feel real?
It is worth being direct about what Odoo was doing here, and what it wasn't. A production airline system is a different beast entirely. Commercial aviation runs on platforms with contractual SLAs, certified integrations with global distribution systems, legal accountability baked into the vendor relationship, and aviation-specific functionality that a general-purpose ERP was never designed to provide. If Vincent had proceeded, the build-out of production systems would have been a substantial project in its own right, drawing on purpose-built aviation software and commercial-grade booking infrastructure.
Odoo was not that system. It was never intended to be.
What it was, was the fastest and most effective way to make a theoretical business case into something a real person could navigate. Configured correctly, it collapsed the distance between the model and the thing being modelled. The product range that existed as structured data in the catalogue was the same product range a user encountered in the storefront. The pricing logic that governed the checkout was the same logic flowing through to the P&L. The demand assumptions in the CRM were the same assumptions behind the revenue forecast. There was no gap between the presentation and the underlying work, because they were the same system.
That coherence was the point. A co-investor reviewing the business case could change a load factor assumption and watch the margin move. They could browse the storefront and see that the fare structure behaved exactly as the financial model described. They could follow a cargo product from classification through to revenue line. The business wasn't being described to them. It was in front of them, navigable and internally consistent.
The financial reporting sat underneath all of it, revenue from passenger fares, ancillary income, cargo charges, the fixed and variable cost architecture that made the cargo argument so important, all generated from the same data, not reconciled after the fact against a separate model.
For a VC evaluating whether to commit serious capital to a greenfield airline in an emerging market, that level of visibility was not a nice-to-have. It was the difference between a proposition and a decision.
The planes, to reiterate, remain extraordinary. But this is what makes them financeable.
The Right Answer Was No
Vincent chose not to invest.
The amounts required were large, aircraft leasing at scale is not a modest commitment, and the risk profile, once fully mapped, was higher than the commercial opportunity could comfortably absorb. Georgia's regulatory environment, functional on paper, carried the kind of practical complexity that doesn't show up in published frameworks. Licences issued through official channels, relationships that influenced timelines, informal costs that were difficult to model and impossible to guarantee. For the right operator, with deep local networks and genuine aviation experience, those frictions might have been manageable. For a VC group without that specific background, they represented a category of risk that the business case couldn't engineer away.
So he walked away. And the project, in the conventional sense, produced nothing. No airline. No aircraft. No passengers on a 6:00 AM flight from Tbilisi to Batumi.
What it produced instead was a complete, detailed, defensible picture of what the business would be. Not what it might be under optimistic assumptions, but what it would cost to build, what it would need to operate, where the margins lived, where they didn't, and what conditions would have to be true for the whole thing to work. Vincent made his decision with full visibility, not based on enthusiasm or incomplete information. That decision, grounded, specific, and made at the right time, was the deliverable.
This is something worth saying plainly, because it runs against the way consulting engagements are usually framed. The measure of a project is not whether it ends in a launch. Sometimes the most valuable outcome is a well-informed no. The cost of that clarity is the cost of the engagement. The alternative, committing capital to a venture whose real risk profile only becomes visible after the money is spent, is considerably more expensive.
What the work demonstrated, across every section of the business case, was a methodology. Start with the market as it is, not as it is convenient to imagine it. Build the product range from commercial logic, not from aspiration. Make the financial model interrogable, not presentable. And use the systems available not just to describe what the business would do, but to show it doing it, within the honest limits of what demonstration means versus what production requires.
For Hatton Locks, that methodology is not specific to airlines. It applies wherever a business needs to be understood before it is built, wherever a product range needs to be designed before it is launched, wherever an investor or a board or a leadership team needs to see the working, not just the answer. The context changes. The approach doesn't.
Georgia didn't get its domestic airline. But Vincent got something worth considerably more than a business plan. He got the information to make the right call.
That's the job.