When we started building LayoverGuard, one of the core product rules sounded almost trivial: if a flight arrives late enough, trigger the fixed payout.
As an engineer, my first instinct was to think about this as a boolean. We have a scheduled arrival time, an actual arrival time and a threshold. Compare the numbers and make a decision.
That assumption survived for about five minutes.
The closer we got to implementation, the less "flight delayed" looked like a simple value and the more it looked like a combination of schedules, operational events, timestamps, data-quality decisions and risk assumptions.
LayoverGuard is still being built, and there are parts of the system we continue to refine. But this has already been one of the more interesting lessons for me as a founder: when software is responsible for turning a real-world event into a financial outcome, things that sounded obvious on a whiteboard suddenly need very precise definitions.
What does "arrived" actually mean?
For a traveler, saying that a flight was late feels straightforward. For a system that needs to make a deterministic decision, it is much less straightforward.
Did the aircraft land late, or did it arrive at the gate late? If it touches down at 3:05 PM but reaches the gate at 3:28 PM, which timestamp matters? What was the scheduled arrival time? Was that the schedule that existed when the traveler purchased the product, or a newer schedule published by the airline later?
For a passenger trying to make a connection, these differences are not theoretical. An aircraft can be physically on the ground while the passenger is still sitting inside it with the doors closed. Twenty minutes between touchdown and reaching the gate may be the difference between making another flight and watching it leave without you.
A rule that started as "was the flight late?" therefore becomes a definition problem. The system cannot rely on an intuitive human interpretation of "late." It needs a precise definition that can be applied consistently every time.
This is where I started thinking less about flight status as a single value and more as a sequence of states, timestamps and observations. That sounds like a software-design detail, but it quickly becomes a product-design question too. Before engineering can reliably implement a rule, the product itself has to define exactly what that rule means.
The schedule is part of the promise
Consider a simple example.
A traveler purchases the product three weeks before departure. At that moment, the incoming flight is scheduled to arrive at 2:00 PM. A week later, the airline changes the scheduled arrival to 2:30 PM. The flight eventually arrives at 2:55 PM.
How late was it: twenty-five minutes or fifty-five minutes?
Both calculations are technically possible. But if a financial outcome depends on that number, the system cannot simply use whichever schedule happens to be easiest to retrieve later.
This was one of the moments where I realized that we were not simply consuming flight data. We were encoding a promise made at purchase.
The timestamp is no longer just a timestamp. Depending on the product design, it can become part of the baseline against which a future financial decision is made.
That creates a number of questions. What should be preserved at purchase time? What happens when an airline changes the schedule afterward? At what point does a schedule change become material? Does the journey still represent the same risk after a significant change?
I am intentionally not answering all of those questions here. Some are product-specific, and some are areas we continue to refine. What is more interesting to me is the process that creates them.
Before becoming a founder, I probably imagined the sequence as relatively clean: define the product, define the business rules, then engineering implements them. In reality, we keep moving in both directions.
Building the system exposes a case that forces us back into product design. A product decision creates a new risk question. The answer changes what the software needs to store or evaluate.
Implementation does not just execute the product specification. Sometimes implementation discovers what is missing from it.
Flight data is an observation of reality
Another assumption I had to adjust was how I thought about flight data itself.
It is easy to imagine an API call like this:
What happened to flight X?
And an answer:
The flight arrived at 15:08.
The real world is not always that clean. Updates can arrive late, some fields may be unavailable, and information can change as an operational event develops. Different systems may also observe or represent parts of the same event differently.
This changes the engineering question from "what does the API say?" to something closer to "what do we know, how confident are we, and is that enough to make a financial decision?"
Sometimes the correct decision may be to make no decision yet.
I think this becomes particularly important when you are trying to automate the customer experience. A traditional claims process can give a person the opportunity to investigate an unusual situation later. If a product is designed around an objective trigger and a highly automated payout experience, more responsibility moves into event detection and decisioning.
Automation does not remove uncertainty. It forces you to define what the system should do when uncertainty exists.
This is one of the less visible parts of event-based financial products. The trigger presented to the customer can be very simple, while establishing reliably that the trigger occurred may require significantly more infrastructure behind it.
Similar design questions appear in parametric insurance. The National Association of Insurance Commissioners describes parametric insurance as using a predefined event or parameter to determine a specified payment rather than determining payment from the magnitude of the actual loss.
The broader lesson is useful even outside insurance: if the experience after an event is supposed to be simple, a lot of precision has to exist before the event.
One hundred transactions may be one risk
Another change in perspective came from learning more about underwriting.
As an engineer, it is natural to think about transactions individually. One traveler requests a quote and the system evaluates it. Another traveler requests a quote and the system evaluates that one. Repeat the process 100 times and, from a software perspective, you may simply have 100 successful transactions.
An underwriter can look at exactly the same 100 transactions and see something very different.
What if all 100 travelers depend on the same flight? What if many of the journeys pass through the same airport during the same few hours? What if a weather system or air traffic control disruption can affect a large part of those journeys at once?
Those risks are no longer independent.
A single operational event can potentially create many financial outcomes at the same time. Evaluating a new transaction therefore cannot always be reduced to the characteristics of that one journey in isolation. The surrounding concentration matters too.
None of this is new to underwriting, of course. What was new to me, coming from software, was seeing how directly it can influence the architecture of the product.
A quote is not necessarily only a question of:
What should this risk cost?
It can also depend on another question:
How much correlated exposure already exists around this event?
That changes how you think about something that, from the customer's perspective, may just look like another option during checkout.
The customer should never need to know about that complexity. Someone building the system definitely does.
The simpler the experience, the more complexity has to move somewhere else
This may be my favorite contradiction in the product.
Almost everything I have described should ideally be invisible to the traveler. A customer should not need to understand schedule versions, event reconciliation, operational states, correlated exposure or how a decision engine handles incomplete information.
The experience should be much simpler: the qualifying event happened, the traveler purchased the product, and the fixed payout followed.
That simplicity is part of what attracted us to this type of product in the first place. But building it has made me appreciate that simplifying the customer experience does not eliminate complexity. Usually, it moves the complexity somewhere else.
If you reduce the need for a complicated post-event process, the system deciding what happened needs to become better. If you want a simple trigger, the definition behind that trigger needs to become more precise. If you want an instant quote, decisions that may traditionally happen elsewhere can need to happen inside a software request.
This is probably true well beyond insurtech. Many products that feel simple from the outside are only simple because someone accepted a lot of complexity behind the interface.
Engineering and underwriting are closer than I expected
I spent most of my career building software, so I naturally approached many of these problems first as engineering problems.
Before starting LayoverGuard, I would probably have described engineering and underwriting as fairly separate disciplines. Underwriting understands and evaluates risk. Engineering builds the software that supports the product.
I don't see the boundary as clearly anymore.
An underwriter might ask what happens if an important source of data becomes unavailable. An engineer might ask what happens if hundreds of transactions depend on the same disrupted flight.
One question sounds technical and the other sounds financial, but underneath they are asking something very similar: what assumptions does this product depend on, and what happens when those assumptions fail?
A timestamp can simultaneously be a piece of data, a product rule, a risk assumption and part of a promise made to the customer.
That intersection is one of the things I have found most interesting about building in insurtech.
When software participates in risk evaluation, observes whether a predefined event occurred and determines what should happen next, the code is not simply supporting the business logic. In many places, the code is implementing the business logic directly.
That makes correctness a very different problem from simply making an API respond quickly.
We are still building
I don't want to write this as if we have solved every possible flight-status edge case. We haven't.
LayoverGuard is still being built. Some rules will evolve, parts of the architecture will become more sophisticated, and I am sure real-world operations will eventually show us situations we have not considered yet.
That is also why I wanted to write about this now rather than wait until everything feels finished.
One of the most interesting parts of building a company is watching a problem change as you move from the idea to implementation. Every time implementation forces us to define something that sounded obvious on a whiteboard, the product becomes a little more real.
"Pay when a flight is sufficiently delayed" is still a simple sentence.
For the traveler, I think it should remain a simple experience.
Making that sentence reliably true is the complicated part.