Build vs buy: the true cost of an in-house SSIM parser

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 iceberg

The visible cost of a home-grown parser is the build. The cost that sinks the project is everything below the waterline:

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.

Cost over time

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.

The opportunity cost nobody prices

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.

When building actually makes sense

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.

Doing it well

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.