[Xcelerate]

I know there's a big push against Not-Invented-Here-Syndrome, but he makes a good point about how a lot of small apps and websites depend on services that drastically change or disappear over the course of a few years. I wonder if in some cases it's better to simply develop an in-house solution for a service — it may be more expensive and less refined, but at least you know that service will be there as long as your company is.

[aikah]

Well StackMob shut down, and Bing Maps are getting more and more expensive... while it's not that difficult to replace a BaaS, it's another matter for map services. And it's going to get more expensive no question.

The time of the freebies for web-development is going to be over soon . I wouldn't trust any service, from Github to google API A or B, to remain free for ever. Especially Github which is moving to "enterprise" at a fast pace. As for PaaS or Saas, given how many businesses closed last year, the remaining offers will certainly get more expensive and any free tier discarded.

But the initial issue is certainly the business model. If you can't even pay for hosting anymore, you need to raise prices. A one time buy wasn't going to cover all the author's expenses.

[manarth]

> it's another matter for map services. And it's going to get more expensive no question

For companies that offer a "free" tier (e.g. Bing/Google maps), for sure, sooner or later, a switch to paid is very likely.

But there are organisations that have a completely different justification for existing: OpenStreetMap springs to mind, as does the UK's Ordnance Survey (which is essentially a Government body, albeit cloaked as a private company, 100% in public ownership). Although they'll always need some source of funding to keep operating, their goal isn't to maximise possible revenue, so as long as it's viable to offer free mapping, they're likely to carry on doing so.

[oconnor663]

I feel like it's worth distinguishing between "not invented here" and "not hosted here" or whatever you want to call it. With other people's code, at least you have the option of making your own fork. With other people's services, the worst case scenario is much worse.

[rgbrgb]

To me it would make sense to go airline by airline (or datasource by datasource as long as they're tied to something users will understand), do the full integration, then advertise which airlines you support. Then you could guarantee a good experience for every officially supported airline. Additionally, as you do this you're building tech that is super valuable (sounds like only 2 other people have done it?).

Real estate data is similarly messy and though we have a small engineering team (3 full-time programmers), we decided to roll our own data integrations with each of the MLS systems we connect to. For us, it came down to the fact that we could provide a better user experience this way (faster, more complete listing data) and that it fits with our approach to product development. Rather than using a data middleman to turn on 50% listing coverage across the entire US, we pick a city or region and piece together all of the listing sources so that when we go live in that region we have extremely high coverage. We then only advertise to users in those areas.

[abakker]

The sad part is that we really need to completely displace/replace the MLS in its entirety. The value prop is there, as is the technology, but it would take a marketing miracle to convert everyone to a new system. Still, it is genuinely amazing that there isn't a better service for it.

[vijayr]

I wonder what other industry can benefit from a unified source of data - so far we have airline, real estate ... Any others?

[timClicks]

Whenever you build a service in someone else's garden, there's always the (fairly high) chance that you'll be booted out at some stage.

In a sense, platform APIs allow the platform owner to understand what customers want without needing to deploy product talent to deploy it. Twitter has perfected this strategy. As soon as a third party comes up with a neat idea with your API, you can build your own "official" version of their app, throttle their usage and hopefully their business model.

[rocky1138]

I wish he would have elaborated more on the services in question which have disappeared over the years. How he dealt with that would make for interesting reading.

[ergothus]

Given the description he listed, it'd be notably more expensive (contracts with various sources), presumably something that only is cost effective with a larger set of customers.