Writing your own schedule parser looks cheap — one engineer, a week, done. The real cost is the maintenance treadmill that follows. Here's the total-cost-of-ownership case, honestly.
Almost every team that works with airline schedules eventually writes its own SSIM parser. It’s an understandable instinct: the format is just fixed-width text, an engineer can read a record in an afternoon, and a first version that handles your files ships in a week. The problem isn’t the first version. It’s everything after it.
The visible cost of a home-grown parser is the build. The cost that sinks the project is everything below the waterline:
| Above the waterline | Below the waterline (the real bill) |
|---|---|
| Initial parse of your own files | Every carrier’s conventions you didn’t know about |
| A grid to view records | Date/season expansion, DST, overnight arrivals |
| “It works!” | Segment data, codeshares, traffic restrictions |
| SSM/ASM change processing | |
| Validation that tells real errors from conventions | |
| Format/standard updates, forever | |
| The engineer who wrote it leaving |
The first column is a week. The second column is a standing team commitment that never ends — because real feeds keep surprising you, and the format and the industry keep moving.
The two options don’t cost the same shape of money. Buying is a roughly flat, predictable line. Building is a line that keeps climbing — every new carrier, every edge case, every season rollover adds maintenance the business didn’t plan for.
Here’s the part that rarely makes the spreadsheet. The engineers maintaining a parser are good engineers — which is exactly why it hurts to have them there. Every hour spent chasing a carrier’s padding quirk or a day-change bug is an hour not spent on the product your customers actually asked for. A parser is undifferentiated heavy lifting: essential, but not a source of competitive advantage. Owning it in-house means paying your best people to maintain plumbing.
The first SSIM parser is a week of work. The tenth revision of it, two years later, is a team’s standing burden — and none of it moved your product forward.
To be fair: sometimes build is right. If schedule parsing is your product, or you have a genuinely unique requirement no tool serves, owning it can be the correct call — provided you go in clear-eyed about the maintenance, the testing, and the key-person risk. What’s usually wrong is building it by default, because it looked easy on day one, without pricing the years that follow.
The whole reason SSIM Toolkit exists is to move that cost from the climbing line to the flat one: read SSIM faithfully — the conventions, the record types, the date logic, the change messages — so your engineers can build what’s actually differentiated and leave the undifferentiated parsing to a tool that does it for a living. Buy the foundation; build the things only you can.
Next: why that tool should be local-first and deterministic.
Sometimes the fastest way to answer a schedule question is to write the query yourself. Here's what it means to treat a parsed SSIM schedule as read-only tables you can ask SQL against — locally, with your data staying on your machine.
A fixed-width schedule file and an analytics warehouse want very different shapes. Getting from one to the other — typed, normalized, partitioned, columnar — is the unglamorous work that makes schedule data queryable at scale.
Almost every airline is investing in AI — but you don't want a model guessing your schedule numbers. The right architecture puts a deterministic engine at the core and AI on the outside, via an open standard called MCP.
