While the app was initially used primarily by individuals who made a few airport pickups per year, today Just Landed is increasingly used by professional limousine and taxi drivers, airline professionals, and travel companies.
So they were seeing increasing use by commercial users. Sounds like a ripe opportunity to start charging for such access.
No kidding, this was the weirdest shutdown statement I've read in a while, "we found users who derive commercial benefit from using us... so we're shutting down"
I think he did touch on that though. Essentially he's selling bread, and he's got to buy scarce flower at high prices in a convoluted system from a small number of farmers, and be forever at the mercy of the flower selling farmers. Only it's data instead of flower.
Further, the data sometimes is bad and causes inaccuracy issues for customers without him knowing, this causes lots of complaints that he has no control over, something that isn't feasible when charging money to commercial users. Not just that, but the price of data is ever increasing, free data is becoming restricted and he needs to restructure as data suppliers go out of business or restructure their API.
I mean there are obviously solutions, like generate his own data etc. But it really looks like he's got other opportunities to earn a living and this isn't the lowest hanging fruit for him.
What I DO find strange is why he's not selling it. I just can't imagine not at least one of the company's he's buying data from wouldn't buy this at a discounted price if need be. Some money is better than nothing.
Creator of Just Landed here. Actually, I have been approached by a number of companies over the years about selling Just Landed, including some household names. The trouble is, almost none of them wanted the app – they just wanted me as an employee. These weren't companies I could get super excited about working for - especially since I love being an entrepreneur and working for myself. Of the few who did want the app or the tech, their quality bar/taste wasn't a good fit, and I worried about how they would treat my users. It was never about the money. Time is my most valuable scarce resource.
Hmmm. If it's about users, then why shutter the service they depend on? I am sure you have throught about this a lot and are probably tired of investing more time and energy in this project, but if you have hundreds of thousands of users, you have a huge opportunity on your hands.
How about:
1) start building your own set of data to complement the bought data. Every time there is an inaccuracy, approach the airline company and start using their data directly. Later on, you can even become one of the companies who provide data to others. When there is a problem ("the data companies are not doing their job") there is an opportunity.
2) change the pricing model to charge big users more. They should be your bread and butter, because they get paid to use your app. You are just a small additional cost to them. You can even lower the initial price tag and charge more for enterprise usage... Since you are better than others (see 1.) the enterprise users will be happy to pay more.
3) failing that, sell to an entrepreneur who will continue. I am sure there are many interested persons and your users would be better served if someone picked up where you left off. Hell, I am interested... :)
Ever think about contractualizing the things that concerned you (like user-treatment) and getting a conditional employment contract, which also featured a limited term?
I hear you on the time point. Thing is, it's hard to get to that place where you have an offer on the table. Starting over would have a time cost, so over the long term, you might've been able to buy yourself more time with the time you'd already invested.
Of course, that also depends on the amount of the offer.
I think that what the other posters are touching on is: why sell bread at all? Why not sell beer? Or ethanol, to gasoline companies? You have a source of flour, and you also have access to customers who are deriving their livelihoods from your product. If the bread market is tapped out and too competitive to make a profit, why not turn around and seek other markets?
In my experience, consumer mobile is pretty much tapped out - it's very difficult to make a living as an independent app developer. But the enterprise market is still booming. Now that the giant consumer applications (WhatsApp, Instagram, Uber, Instacart, etc.) have been found, there's a long tail of smaller niches that'll pay good money for specialized services.
But he doesn't have the source of flour -- he gets the flour (data) from unreliable/expensive sources and turns it into bread. The people with the data are the ones who are in the leverage position.
You touch an important point. I'm in the process of winding down an app that relies on scraping a variety of badly formed data - there is commercial interest, but it is really difficult for me to make people pay for something if I can't guarantee the quality of the data- which after struggling for a couple of years chasing obscure data format changes, I was not looking forward too. I'm sure there were other factors, but I completely understand the app creator's decision to shutdown rather than enterprise up with that in mind.
I've worked in a similar situation, providing pricing/inventory information to buyers from vendors, and it's hellish as a middleman with limited clout to ensure vendors remain consistent in transmitting up-to-date pricing and inventory. When one side encounter inconsistencies, middlemen always get the blame despite the other side being responsible for providing the information. Hence why I sympathize with the app developer.
You got it. To profitably support commercial power users I would have had to change the business model to a pay-as-you-go subscription model. I considered doing this in a way that wouldn't shut out my casual users (for whom I created the app in the first place, and who are still the majority), but I had serious doubts about the willingness of taxi and limo drivers to pay for Just Landed on an ongoing basis.
The proliferation of half-decent free flight trackers (albeit without the unique airport pickup focus), the other systemic problems mentioned in my post, and the increasingly common cannibalization of utility apps by Apple's iOS itself, led me to the conclusion that such an endeavor was likely doomed to fail.
Just because you can find passionate users doesn't mean you've found a good business, and that was the case here.
Have you tried it? What if instead of "we're shutting down", you'll say "from now on the service will cost 5 bucks a month" (or we'll close)" and see what happens?
Exactly from the article he said they used 500x more data (which I am sure is a total broad guess, but I could easily imagine 100x or more for someone hitting an airport up every day)
Failure to monetize such as hypertargeted/local ads/deals or freemium features.
Winners tend to turn challenge into profit opportunities rather than give up and disappoint many people when they had something sizable which could be sold to someone whom can fix it or fix it themselves.
Too often, when people whom are uncomfortable with uncertainty and don't know what success looks like, they give up and throw away opportunity which may never come again because of their past behavior / reputation for not finishing things. My cousin nearly had a florist shop by having tons of orders, but gave up when he didn't know what to do by feeling overwhelmed... and I was so disappointed that he didn't handle it better to come out ahead in something he had passion and opportunity that passed by. (Self-sabotage or novice mistakes, who knows.)
I see these shutdown notices not as some self-deprecating contrition but as braggging about letting people down, destroying value and wasting their and all their customers' and investors' time and money... don't shutdown when you have a good team and customers, pivot or sell. (Don't squander assets: talent, social or capital.)
I've been thinking recently about crowdsourcing our own dataset of airplane data. When you get on a plane, tap a button that says 'we're delayed 5 mins'. When you land, tap a button that says you've landed. In fact, you probably don't even need users to tap those buttons. The better way would be to use the accelerometer and barometer to automatically detect takeoff and landing.
Airplane data sources are ALWAYS wrong in my experience. I have been on a flight that was 2 hours late but all the flight data sources/apps would say 'On time'. Bullshit. And very often there are delays that the flight data does not account for, but are real delays. User's phones could provide a much more real-time view on where airplanes actually are than any existing flight data source. I hate sitting on a plane and knowing that I am more up-to-date on how late we are than the official data source is. That's super annoying and it seems like there's an 'easy' fix: just build a new kind of crowdsourced, real-time flight data service.
Would that even be possible? I know I've never been able to get GPS to work reliably on any phone I've owned while on an airplane (even holding it up to the window), and presumably cell tower location wouldn't be available either above a certain altitude.
Edit: I am utterly wrong about my first point, the export controls don't kick in til 1,200mph or 59,000 feet; Both much faster and higher than standard commercial jetliners. [1]
GPS on your phone can't, by US law, work when you're in a plane. It is required that consumer GPS devices stop sending data when it is traveling over a certain speed, to prevent them from being repurposed as guidance systems for cruise missiles. Seriously.
You don't really need it, though. If you've got two or three people on the plane, the signal from when they all turn off airplane mode is a fairly good landing indicator. Takeoff is less steady; You're theoretically supposed to turn off your phone when they close the cabin door, but most people I know don't until they are actually taxiing down the jetway.
Out of curiosity, do the GPS chips stop working above a given speed or it's the smartphone sw that must stop reading from them to pass import controls? And what about GPS chips manufactured outside the US, put in phones sold outside the US by non american companies (I'd say the vast majority of the market), are they still subject to that limitation?
I've seen enough cases of people creating crappy free "replacements" for premium apps or services, and people flocking to them, that I don't know if you'd actually need to fully replicate the data sources. Just find something "good enough" and people will come. Or pay for a little while, planning to "figure out monetization later" and then fail in six months or a year.
That just means that the free alternatives won't stick around, but you could still get a steady stream of people who see your prices, assume they can undercut you and still make a profit and take away a few months of revenue each before they run out of money and give up.
This sucks for us long-term users of Just Landed. I want to congratulate John for making something people _clearly_ wanted. Apparently sometimes that's not enough...
This jumped out at me:
"...Just Landed has outlived several of the services that it originally depended on, and each time a service provider has disappeared..."
This statement refers to the less than 4 years old app, which speaks volumes about value proposition of for-subscription-cloud-based APIs. Just Landed is a relatively simple, focused app built by a small team, yet in this short time it has suffered several (!) hits from disrupted availability of the API providers.
How can one expect to build a big business based on considerably more complex software using such APIs?
Compare that to the pains Microsoft has historically gone through to keep ABI compatibility with decade-old systems. I even have doubts about long-term availability of half of AWS services.
Kudos to John for running Just Landed for so long.
My buddy enjoys rendering weather data. Using just one source- NOAA - he has to update the app several times a year to respond to their capricious, random changes to web interfaces, server names, random hosting requirements and so on. Its a real thing to factor into any data-repackaging app.
Definitely true. APIs aren't standard, they aren't guaranteed, and they require constant vigilance from the consuming app's POV. Notably though, these aren't mostly paid APIs. If its free data, then the developers should do what they think best presents the free data they are giving away.
On the other hand, if you want a great example of how to do it right, salesforce.com has a pretty great API strategy. rather than try for some "version-less ideal" API, they release new versions and new endpoints, and have only ever deprecated old APIs for security reasons.
I suspect that when APIs are changing all the time, it is because the API's implementation is too close to the underlying application or data structure. In an ideal state, the APIs are only supposed to present data in a certain way, and shouldn't necessarily be determined by the actual structure of that data in an application or database.
Assuming you mean iOS app which is hard to update instantly. Maybe he would benefit from creating his own middle-man server-api that the app talks to. That way he just needs to update the server-code and the app will still get the right values.
"The first thing that makes running Just Landed difficult in the long-term is a serious lack of innovation in the flight data industry."
Our company shut down because other people didn't innovate enough, not our fault.
"An app like Just Landed relies on access to high quality flight data to function correctly. "
We created an app based on data that doesn't exist. Not our fault, somebody else failed to create that data.
"Traffic and mapping data in particular, much of which used to be free, has become quite expensive, and is now tightly controlled by big companies under oppressive Terms of Service."
Other companies refuse to give us free services, and want to keep their valuable data restricted under oppressive terms of service. Not our fault, how could we expect that people wouldn't give us free stuff?
"These power users consume 100–500 times as much flight data per year as casual users, and so the cost of supporting will soon begin to overwhelm revenue from new app sales."
We failed to price the app correctly, since we're charging a one-time fee for a continuous service, but hey, not our fault again, who would have thought that people who buy our app would use it?
"Essentially, there’s a massive oversupply of apps, and the app markets are now saturated and suffering from neglect and short-term thinking by the companies who operate them."
There's too much competition! Seriously, it's all the competitor's fault, lowering prices as if there's no tomorrow. How can we be expected to make money with such cutthroat, dog eats dog competition?
Seriously, what a completely lame excuse. [Edit: that was unnecessarily harsh, my apologies]
Sorry for my rant, I guess I'm in a bad mood today.
A little harsh. 'Not our fault' and 'beyond our control' are not the same.
I read the reasoning to be a more pragmatic appraisal of the predicament they found themselves in - "Just Landed, ... has been on the wrong side of these trends"
But on the other hand, the key failure point for the app is pretty obvious: its revenue is a one time fee, and the costs are a function of how much people use the app. Based on the post, they clearly mispriced the app, since it depended on new sales to fund existing customers.
This isn't very different from a pyramid scheme (without the intention to fraud, naturally): you need to keep growing indefinitely to stay afloat, clearly impossible. When sales flattened (which they did) the company would go bust (which it did).
Another way to look at this is treating a sale as an annuity. If I sell an app for $10, expecting users to use it for 10 years with a 10% WACC, this would be equivalent to receiving a $0.13 subscription fee from each customer over the 10 years.
Therefore, if your variable cost per customer is higher than $0.13/year, you're in serious trouble. Even if it's lower, you might still not break even.
I doubt if users would have paid much for this kind of App. As its use-case seems to me, a cousin of lot of other free apps like maps (directions), which are done by giants. So basically its something which people need, but have mental categorization of it as a near-free thing.
For roughly the same amount of effort, that you put in this app, you could have a flight search engine. Where you will get something per transaction.
Not taking away from the app. From what I read here, it seems it was nicely done, and must have been quite useful. But its about how much people can pay per transaction (if I can call it that.). Freemium ad based model, has been the dominant Internet culture so far, for information from the web. That is a big barrier, in my experience for these kinds of apps to do well.
I'm always curious why companies like this one choose to charge for their app as a one time fee when, to support the app, they have to subscribe to data feeds which cost money per month. I feel like you have to have a subscription model for that unless the price per month is just so low that, with a small amount of volume, you can easily make up for it.
Either way always an interesting write-up. I do find it odd that so many in SV use the term "sunset" when their company is shutting down. Seems like a weird spin.
From a purely practical standpoint, it's easier to charge for the app and let Apple do the billing and payment processing, than to set up a system to handle recurring billing (and then you need to deal with cancelations, chargebacks, etc.). I've gone through this thought process for a few side projects, and unless I anticipate really large MRR, it's hard to convince myself to go through the hassle of setting up subscriptions.
I think they're restricted to certain types of apps, though? The app review guidelines[0] say:
> "Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected"
I assumed that's why so many iOS apps use non-recurring billing instead. You can still sell access to your service, but users have to manually purchase at each subscription interval.
This app did sound to me like an enterprise business app. So I agree with other commenters here that the author didn't pivot soon enough to business users.
> than to set up a system to handle recurring billing (and then you need to deal with cancelations, chargebacks, etc.).
You just plugin the Stripe SDK and set up a Stripe account and it's done. It's not hard. It takes like half a day. You don't have to do any of this manually. If you're a tiny team and you are doing this manually you're doing it wrong. I've never had to worry about chargebacks or cancelations being a problem.
You cannot use the strip SDK for iOS devices. IAP only. And by that I mean, any situation where you want to purchase something in-app (an upgrade, premium service, etc.) and not a transaction for a real-world good. Real world goods can be purchased using whatever, but digital goods must use IAP.
Never used them but https://www.chargify.com/ is supposed to be a service for this. Of course then you run into the disappearing service problem again.
I work for Chargify and wanted to comment on the "disappearing service problem." Chargify has been around for over 7 years and has been growing and profitable for the last 4 years. If disappearing services is a concern, we do not plan on going anywhere for a long time :)
When you design a service but charge for it as if it were a product, the inevitable result is that in short order you discover that if there is a demand for the service you offer, the demand continues – but your charging does not.
You would think that the consideration of "how will people actually use this application if we're successful?" would come up a little earlier in the design process than four years after implementation and deployment. And yet…
They might like that it implies more of a gradation than a binary on/off. A lot of these companies do help people migrate, etc. before going completely offline.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
This is possibly the most interesting fumblebrag that I've read in a while. It has a few issues which have been hot on HN recently as well as some age-old problems.
The dependence on third-party services like maps, messaging, flight data, etc. is an interesting topic. Services that help you to get up and running in a couple of clicks are awesome at first. But they can become a burden when your usage goes up beyond a trivial amount. This is a great lesson about thinking ahead when choosing third-party providers - either by passing the expense along to your customers or having a roadmap to phase them out when you hit a certain volume.
Another point is the one-time pricing which, in my mind, is somewhat of a ponzi scheme for a business model. I always cringe a little when I see a cool new app with a "one time payment for life!" pricing. You just can't support customers forever with a single lifetime payment unless you are earning revenue in some other way (i.e. advertising). It's easy to think that you'll continue to gain more customers forever, but you're setting yourself up to be crushed by your own success. Unless you're planning on regularly releasing new apps and/or in-app purchases for your customers to purchase, it's not a long-term business model.
Sorry to see the Just Landed go - it looked like a cool app. I think there is a lot to learn from this post so thanks to the author for posting.
In theory, you can charge your average lifetime value upfront.
In practice, for a good app the lifetime benefit to users vastly exceeds what anyone would reasonably pay upfront. For example, I've paid hundreds of dollars to Dropbox over the years (and feel like I've gotten well over $1,000 of value)—but I would have totally balked at paying even $200 on signup.
That is true, and to make matters worse it's probably near impossible to figure the right amount out when you've just started the company. You don't always know how people will wind up using your app.
The #1 reason why this app failed is because people like me, and especially my mother, who would have been a power user...did not know it existed until this Medium post. Your problem has less to do with the app itself and more to do with how it was promoted and marketed.
In case you didn't know this, mass marketing is expensive.
You don't use the marketing channels you wish you have, you use the ones you can make a profit off of. If you have to ask, they probably won't reach you.
Active users = check
Value delivered = check
Inability to develop profitable GTM plan = check
I didn't read about funding in the article, but outside of $ a VC or Angel will provide a network and path to solve GTM challenges AND get you in front of the right people for an exit.
I'm sure if this app called an Uber/Lyft timed to plane landing it could find a home...
> With well over 2 million apps by now (officially 1.5M as of July 2015), the iTunes App Store is an incredibly crowded place where it’s almost impossible to get noticed. Despite the persistent myth of the app developer millionaire, it’s extremely hard to make a profit—let alone a living—as an iOS app developer. The Google Play Store is a similar story, except with the added bonus of rampant piracy and a zillion devices to support. There really isn’t gold in them hills, at least not anymore, and independent app development will soon be in sharp decline, if it isn’t already.
Is this true? Is the app store deceiving developers by pretending that earnings are better?
I wouldn't go as far as saying that Google and Apple are actively deceiving developers. However, they do have a strong incentive to keep things the way they are, and to keep the end user ignorant of how the app economy functions.
You might be surprised to know that many customers on the App Store, and even some members of the press, seem to think that apps being featured by Apple have been bought by the company. I would get emails like: "how have things changed for you since Apple bought your app?"
If people knew how bad the app economy has become, there'd be far fewer app developers than there actually are, and the device makers would have a serious PR problem on their hands.
In the end though, I do believe that the short-term thinking I alluded to in my post will soon come home to roost. I do hope that Apple and Google course-correct before we end up in a situation where indie apps are a distant memory. It's in their long-term interest to keep the App Store diverse and the app economy healthy.
I wouldn't be surprised if it was more possible to make money on the Windows side - not so much with Windows Phone as with Windows Universal apps on both the Desktop and Mobile Windows Store.
The ending of "Project Astoria" that could have let some Android apps run on Windows 10 Mobile has undoubtedly hurt Windows Phone because of the dearth of good apps, but that same lack means that a quality application could still be a smallish fish in a small pond rather than a minnow in a large lake - even with the disparity in adoption 1% of the smartphone market is a significant number of devices. If an app is also something that's viable as a desktop or tablet app, that may provide enough of a larger market over time to keep some folks in business.
In the grim dystopian present, writing an app is basically purchasing a lottery ticket. Developers are locked in a race to the bottom selling apps for one or two dollars and giving a third of the proceeds to the platform owner.
Sad to see companies like this go. The founder stated in the article above that the cost of the data being expensive was part of the demise, I wonder if croud-sourced solutions such as https://flightaware.com/commercial/flightxml/ (FlightAware) was ever used. That said any time I walk into an FBO or look on the screens for arriving or departing flights in general aviation, FlightAware data is the only thing I see people use. It could be because FlightAware owns the data (which is crowdsourced in a similar fashion to WeatherUnderground stations) they provide a service that Just Landed simply can't compete with.
As with anything in Travel outside of actual aviation aspects these types of services such as just landed, to me, feel more like Value Ads than core products. I personally just use google to track the flight of an arrival and can do it from my phone's browser by typing the flight number in a google search box.
Since a screenshot of the Just Landed app shows up in the image carousel on your link, I am assuming that they used FlightAware for their data. FlightAware charges people for API access, and also specifically provides a set of tools for FBOs (https://flightaware.com/commercial/fbotoolbox).
Do these middlemen have to strike deals with the various airlines, or are they simply accessing public APIs that generally stink? What order of magnitude, cost wise, do these airlines charge in the deals? Could I, $random_guy, make a deal with $random_airline, for an amount that is sustainable without any special kind of funding?
In what is probably the biggest case, FlightAware, a lot of the data comes from a fleet of users running ADS-B[1] receivers feeding data into their system. ADS-B data is what Air Traffic Control uses to track planes, and it's receivable using using a cheap TV tuner and a raspberry pi[2]. It ends up being probably the best way to track planes very precisely, as long as you can get enough coverage, which flightaware manages to do pretty well [3]. They then package this data and sell it via an API/tools for Fixed Base Operators or apps like Just Landed.
Our network ADS-B ground stations is one of our fastest-growing data sources, but we also get data from the FAA, other national aviation authorities (UK, Australia, Eurocontrol, Central America, etc.), directly from airlines, satellite avionics providers, etc. Live flight tracking is a deceptively difficult problem - on the surface it seems as if you could simply collect data and regurgitate it (that's what I thought before I came onboard), but there is actually an enormous amount of processing and inference based on sometimes incomplete, inaccurate, and conflicting data, even for mainline airline flights. That's not even getting into GA or flights in areas of the globe where we lack complete coverage. It's a really interesting set of problems!
It sounds like FlightAware is a much smarter, and more technologically innovative company than some iOS app maker. How come we aren't reading an article about them?
I use FlightAware all the time, but didn't know they pull the data directly from the planes.
I'm guessing FlightAware is one half of the "duopoly" spoken about in the submission.
Edit:
Looks like the cost per 1k queries for flight arrival times is $7.90 USD, which is a Class 2 query @ $0.0079 USD per query at the highest tier [0], but it goes down with more queries. You actually also probably want to pull their "AirlineFlightSchedules" API data to pull initial schedules for the day, which is a Class 1 query @ $0.0120 [0].
How many flights globally, per day? ~100,000 [1]. Once you fall down into their tiered pricing, and use their "15 results per query" rule, it amounts to ~$80. Once there is flight information for each flight for the day, there will likely be periodic update times. There's a firehose feed, but they don't specify pricing, so I'm not sure what the cost is to provide live updates.
If we say 5 updates per flight (total guess), that becomes ~500,000 queries daily of Class 2 data. I'm confident there's a way to batch these, so this comes down to ~33,334 requests, which puts us at ~$181.34 in additional charges per day.
So our daily costs are now about ~$261.34, or ~$7,840.20 per month, assuming they're not pulling data on-demand. This changes somewhat significantly if an app (correctly IMO) only pulls data for flights it's asked about. You get to cut out the $80/day entirely, and only some portion of the $181.34 is actually paid each day. If you consider the ~28,500 domestic flights in the US [2], and if app users only search for half of those, costs drop to ~$162 per day, or $4,860 monthly (plus the unknown cost of the firehose).
So, because of the cost of the data alone, your app will have to pull in a bunch of users. Wait, how many? Let's figure that out, based on an estimation strategy I pulled off of Quora (so it might be wrong) [3]:
Each user checks their flight status 3 times, which takes them ~1 minute overall to read, so we get 2 impressions [3]. I don't really know what these other two things are, but I guess we'll next assume 100% fill rate and eCPM of $3. But that's just per flight. 694 million passengers took flights in the US this year [4], and while I know we're getting into some pretty speculative territory, that's at least 2 flights per person per year, not to mention all the other people who also check on flight statuses of their friends/family. I feel comfortable saying that each person would check this app at least 15 times a year (you'd use it if you had it), or 0.04 times a day, which would give 0.08 impressions per day.
To cover costs for the data alone, you'd need 810,000 users. Even if each person used this app twice as often, you'd still need 405,000 users. That's completely untenable. I'm actually wondering if my math and assumptions are correct...
I can see something like this being able to work without paying for access to a flightaware api or something similar as ADS-B rolls out fully. A lot of aviation companies still pay hefty fees to tap into ATC data, that will essentially be made free. ADS-B Out broadcasts identification, position, altitude...
With more aviation geeks out there supplying the data, people won't be reliant on centralized sources of info.
Also, ADS-B rollout isn't entirely necessary. It's possible to triangulate places with the older Mode-S transponder through MLAT as long as you have enough receivers in the area.
I have been approached by a number of companies over the years about selling Just Landed, including some household names. The trouble is, almost none of them wanted the app – they just wanted me as an employee. These weren't companies I could get super excited about working for - especially since I love being an entrepreneur and working for myself. Of the few who did want the app or the tech, their quality bar/taste wasn't a good fit, and I worried how they would treat my users. It was never about the money. Time is my most valuable resource.
Yeah; unfortunately this is not a space that's super profitable. There used to be a bigger need for it; but airlines have gotten a lot better about communicating delays to customers, so I'm not sure this kind of app is necessarily needed anymore.
Even the "leader" in this kind of app -- TripIt -- has basically been reduced to a free giveaway for users of Concur's (owner of TripIt) corporate travel booking platform.
This cries out for Apple to support update pricing. However the likelihood of that every happening is less than giving the NSA a backdoor. Update pricing would make Apple money (not that it needs it) and change very little but the desire is zippo to bupkis to do it. This would allow smaller companies to survive. Oh well, doubtful it rises to the level of anyone caring.
Paid updates would be a disaster. Can you imagine giving every two-bit developer the power to say "this update costs $0.99" and all they did is change the font. Your phone would be a sea of shitty paid updates. Many customers would not update their apps, and the user base would become fragmented. Customers would become wary of buying apps for fear of being ripped off by endless updates.
You may say "ah but the good developers wouldn't do that" but unfortunately someone's always gonna piss in the pool.
The current buy-once model is better. Subscription/IAP model is better for something like this.
Is that a problem for anyone other than the app developer? It doesn't seem to be any loss to either the end user or to Apple for them to keep running Fart Simulator 2014 forever. If the app developers actually need all their users on the latest version, then they're incentivized not to charge for updates (or to do so in a reasonable fashion).
So, they went broke because the industry didn't standardise their data so a third party could scrape it for fun and profit.
Talia, is that you?
--
"An app like Just Landed relies on access to high quality flight data to function correctly. However, since the airline industry is extremely fragmented, and uses antiquated IT systems and many incompatible data formats, it is not practical for a small independent developer like us to negotiate data-sharing contracts with each individual airline, and then unscramble their jumbled data feeds into a usable format at a reasonable cost."
I would have just charged more money for the business users, and make more revenue. But then again, it's probably one of many little things that ultimately led to this decision.
Lots of people have asked me this, or suggested it. I have been approached by a number of companies over the years about selling Just Landed, including some household names. The trouble is, almost none of them wanted the app – they just wanted me as an employee. These weren't companies I could get super excited about working for - especially since I love being an entrepreneur and working for myself. Of the few who did want the app or the tech, their quality bar/taste wasn't a good fit. It was never about the money.
He brings up some interesting points in the article, but I think the real reason for failure is 1) creating a niche app rather than a scalable one, and 2) not aligning the business model correctly.
As much as it might feel like selling out to the founders of this product, providing the tech in white-label or licensing to travel groups such as Kayak for example could of been a way to at least keep the doors open.
That would be a great idea. I guess you would have to have a buffer to cover longer than usual appointment times. That type of app could be used for so much too. Parents dropping their kids off at the movies, it would give them the travel time for when they need to come back based of the length of the movie.
What about reinstalls? What about developers/tinkerers who are probably flattening their devices on a regular basis? What about one person with multiple devices?
Presumably that feature can only work if you redownload the app from the Play store. If you're restoring a backup or using any other method, it won't get counted.
While the app was initially used primarily by individuals who made a few airport pickups per year, today Just Landed is increasingly used by professional limousine and taxi drivers, airline professionals, and travel companies.
So they were seeing increasing use by commercial users. Sounds like a ripe opportunity to start charging for such access.