FlightWatch is a small service that watches for cheap flights and sends an alert when one matches what you’re after. The scheduler works. Deduplication works, so you don’t hear about the same fare twice. Discord and email alerts work. There’s a test suite.
It doesn’t do anything useful, because the flight search API it was built on stopped letting new users in.
What happened
We built on Kiwi.com’s Tequila API because it was well documented and easy to start with. By the time we wanted to take FlightWatch further, access for new partners had effectively closed. The code was fine. There was just nothing for it to search.
What we’d do differently
Check the door before building the house. Before writing code on top of a third-party API, find out whether a new business can actually get production access, on what terms and at what cost. Public documentation doesn’t mean public access.
Put the provider behind an interface from day one. FlightWatch’s search logic knew too much about one provider’s response format. If “search for flights” had been a small interface with one implementation behind it, swapping providers would be a day’s work instead of a rewrite of the core.
Know your plan B before you need it. For flights, that means knowing which alternatives exist and roughly what they cost before you start. The time to research a backup is when you don’t need one.
Treat data access as the product risk. It’s tempting to see the API as plumbing and the app as the product. For anything built on data you don’t own, it’s closer to the other way round.
What we changed
We’ve carried this into everything since. InkOnMe generates images through a provider interface, so the model behind it can change without touching the rest of the app. In ArtCarli, the sources for people data sit behind a similar layer, which is a big part of why moving them onto licensed providers this summer went smoothly.
FlightWatch itself is paused until we pick a new data source.