Nobody builds a startup to write parsers. That's what makes the ones who do so difficult to displace.
Flighty, the iOS flight tracking app famous for predicting delays before airlines acknowledge them, just shipped a feature called Airports , transforming it into a comprehensive airport data platform spanning more than 500 airports worldwide. The Hacker News engineering community is already dissecting the architecture, and a parallel post about a developer who took a pest control technician job to build better vertical SaaS hit 309 points the same week. Two very different products. The same underlying thesis.
The next wave of defensible startups is being built by teams willing to normalize the data nobody else wants to touch.
2019, 2022: A Flight Tracker With an Accidental Data Pipeline
Flighty started with a tight premise: know more about your flight than the airline tells you. Delay predictions, gate changes, tail number tracking , the kind of information frequent flyers refresh obsessively.
But to deliver accurate predictions, the team was already ingesting data from FAA feeds, multiple airline APIs, ADS-B transponder signals, and historical delay pattern databases. They had built a multi-source data normalization pipeline before they had a name for it.
The airport data was always sitting in the margins of their flight models. Terminal layouts. Gate distances. Security checkpoint throughput. Every data point adjacent to "your flight" but not technically about the flight itself. For years, that data lived in the pipeline but never surfaced in the product.
2023, 2024: Confronting the Fragmentation Problem
Anyone who's tried to build anything with airport data knows the terrain. There is no unified airport API. Not even close.
Terminal maps come from individual airport authorities, often distributed as PDFs updated on schedules ranging from "quarterly" to "whenever someone remembers." Security wait times come from TSA's MyTSA feed, which is crowd-sourced and notoriously inconsistent. Lounge data is scattered across credit card reward program databases, Priority Pass networks, and airline alliance portals. Restaurant and shop hours live on individual airport websites that get redesigned every 18 months, breaking every scraper in the process.
In Hacker News discussions, engineers examining the feature identified at least 14 distinct data sources that Flighty appears to be normalizing into a single interface. One commenter noted that TSA wait time data alone requires handling three different timestamp formats depending on which airport originates the feed.
This is the engineering problem that makes vertical data aggregation simultaneously painful and defensible. The work is unglamorous. The moat is real.
March 2025: Airports Ships
Flighty's Airports feature, announced on the company's product page, covers more than 500 airports worldwide. The feature set reads like someone catalogued every airport-related frustration and built a single answer:
- Real-time security checkpoint wait times with confidence indicators
- Terminal-specific maps with gate-level navigation
- Lounge availability and access rules across multiple card programs
- Food and retail listings with real-time open/closed status
- Walking time estimates between gates, calibrated to each terminal's layout
The engineering community began dissecting implementation details almost immediately. Several threads focused on what one commenter called "the staleness problem." Data from some airports updates every five minutes. Others update every two hours. Some haven't pushed a feed update since last quarter.
The apparent solution: confidence scoring on each data point, with freshness indicators shown to the user rather than a binary show-or-hide decision. That design choice is worth studying. Most apps either display stale data without warning or refuse to show anything below a confidence threshold. Flighty chose transparency over false precision.
The Parallel Story: Pest Control and the Same Thesis
The same week Flighty shipped Airports, a post titled "I wanted to build vertical SaaS for pest control, so I took a technician job" hit 309 points on Hacker News. According to the piece published on OnHand's blog, a developer spent months working as an actual pest control technician before writing a single line of code.
Different industry. Identical instinct.
The developer discovered that building software for pest control meant understanding data flows no outsider would guess: inspection reports in wildly inconsistent formats, chemical application logs with regulatory requirements that vary by state, scheduling logic that depends on pest species and treatment type, customer communication patterns that differ based on whether you're dealing with termites or rodents.
Both stories exemplify what I'd call the "parser-as-moat" pattern. The product isn't the interface. The product is the normalization layer that converts fragmented, inconsistent, domain-specific data into something structured and useful.
What HN Is Actually Dissecting: The Architecture
The Hacker News discussion went deeper than usual on Flighty's technical approach. Several themes emerged:
Hybrid data pipeline. Commenters speculated that Flighty uses real-time feeds where available (ADS-B, some TSA data), scheduled scraping for airport authority sites, and community-sourced corrections for data like seasonal restaurant hours that no API covers reliably.
Offline-first caching. Multiple engineers noted that airport data appears to be pre-cached for offline use , a detail that matters because airport WiFi is famously terrible. The implication: aggressive pre-fetching based on your upcoming itinerary, downloading all relevant airport data before you lose connectivity. If you're building for any domain where user intent is predictable, this is the move.
Map normalization. Airport terminal maps are a cartographic nightmare. Some airports provide vector data. Others provide raster images at inconsistent scales. A few provide nothing at all. Flighty appears to have standardized everything into a consistent rendering layer , a non-trivial problem the thread spent dozens of comments exploring.
The Timeline of Parser-as-Moat Startups
Flighty's move fits neatly into a pattern that's been compounding for years:
2018, 2020. Plaid aggregates fragmented banking APIs into a single developer interface. Reaches a $13.4 billion valuation.
2020, 2022. Flexport normalizes global shipping data from hundreds of carriers and customs systems across dozens of countries.
2023, 2024. Vertical SaaS plays emerge across construction, healthcare logistics, and food supply chains , all built on the same thesis of normalizing industry data that exists in 47 different formats.
2025. Flighty extends flight data aggregation to the full airport experience. A pest control developer embeds in the field to map data flows before writing code. The pattern is now explicit enough that Hacker News recognizes it on sight.
Three Engineering Lessons From Flighty's Approach
Confidence scoring beats binary availability. Don't hide data because it might be stale. Display it with freshness context. Users in high-information, high-stress environments would rather have imperfect data with a trust indicator than a blank screen.
Pre-fetch based on intent signals. Flighty knows your itinerary, which means it knows which airport data you'll need before you need it. Any product where user intent is predictable can apply this pattern: download the data while the user still has connectivity, serve it when they don't.
Expand from adjacency, not ambition. Flighty didn't set out to build an airport data platform. They built a flight tracker, realized they were already ingesting 70% of the relevant data, and extended from there. The best vertical data products emerge from teams already embedded in the pipeline , not from teams who read a market report and decided to "disrupt airport information."
What This Means
Flighty's Airports isn't just a feature launch. It's a proof point for how vertical data aggregation compounds. Once you've built the normalization layer for one data type in an industry, extending to adjacent data types becomes dramatically cheaper. Your parsers are built. Your data relationships are mapped. Your update cadences are calibrated.
The Hacker News community's response , to both Flighty and the pest control post , reflects a developer audience that recognizes this pattern and respects what it takes to execute. Writing parsers for 14 data sources that change without notice isn't glamorous. Spending months as a pest control technician to understand inspection report formats isn't a YC demo day story.
But these are the teams shipping products that actually work. The moat isn't the model. It's the parser.