Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Thousands of engineers use Airplane to rapidly build UIs and workload automation for engineering, support, and operations teams."

"As part of this transition, we will unfortunately be sunsetting the Airplane platform on March 1."

So these "thousands of engineers" will only have two months to redo all of their work?



Don't integrate early-stage SaaS as critical to your business is the main lesson here. You get laid-off just like their employees when they rush toward a shitty acquisition.


>Don't integrate early-stage SaaS as critical to your business is the main lesson here.

Let's be honest, nobody had 'Airplane' as some critical part of their business.


You might be surprised how many shadow IT projects end up becoming load-bearing members in businesses. (I think this is mostly a good thing, because it works out a lot more often than it fails, but when it fails like this, it can be very disruptive.)


We use it for customer support


if everyone was as blanket-critical of early stage SaaS as you we would get a lot less innovation (or at least challengers to keep incumbents honest). someone needs to be discerning of team/product quality, someone needs to take risks to solve pain for their stakeholders. there are good startups that are good partners, there are startups that give a good try and dont make it, and there are plain bad startups. don't throw everyone under the bus


My company had a significant product based on an early stage startup's product -- before we signed a license with them, we negotiated a code escrow agreement with the company. And it was good that we did because about a year later they got acquired by a company that didn't want to continue selling the product we used, but we got the source code so were able to maintain the product. We picked up a couple of the developers that were working on that product too.


How many businesses have the in-house expertise to maintain a defunct codebase? And for how many of those that do is it actually an optimal use of resources?


When we took over the codebase, it was 50-50 whether or not we'd really continue with it long term or just fix a couple important bugs and work on porting to something new. Then we managed to hire a couple of the core devs from the product and decided to keep it.

We were lucky that they did a good job with the escrowed code and had everything we needed to build the software on day one.

>And for how many of those that do is it actually an optimal use of resources?

That's impossible to answer -- depends on how hard it would be to port to another product to fill the need (assuming you can find such a product), or write a new system from scratch to do what that product does.


This is a story about successful CYA, not a recommendation to go balls deep on any hawt sAas that comes your way.

But also, a lot of companies have engineers that can.. Engineer. Often it's more an availability issue than expertise.


> we negotiated a code escrow agreement with the company.

really curious of the terms of that


Me too, only a few people in the company knew the terms of the agreement, apparently it was the only code escrow agreement that company made and it was protected under NDA. I don't think we paid a premium for it, but signed a longer term licensing agreement.


This is more common practice than you think. But it is common in enterprise realm not in SaaS realm where you just self signup and it is Product-led upsell.


woudl love to learn more - what startup was this? why could they not have gone out to market to compete with you instead of letting you whitelabel their product?


It was a pretty low level product near the bottom of our infrastructure tier and we built everything on top of it. It worked well for our specific use case, but apparently not a general enough need to succeed on its own. It's not like we took their product, added a new skin and sold it as our own.


I don't understand how any tech startup gets any adoption from business users with critical use cases. The risk seems obviously disqualifying.


One typical strategy is by having all core functionality open source, so that people can self-host, if necessary.


Potentially an acquihire due to exhausting runway? Would align with the idea of a startup funding crunch in the current macro, but only someone with transaction details and willing to violate an NDA (if one exists) would be able to share (if details aren’t going to be made public). Depending on comp, benefits, and infra, it is not outside of the realm of possibility to burn through $32M (Sep 2022 Series B raise) in ~15 months (~$2.1M/month).

Sucks for customers but is hopefully a soft landing for Airplane team ending up in an org that hard pivoted to B2B recently (and hence can afford to continue their employment).

https://www.crunchbase.com/organization/airplane


I wonder if there's a business/service that estimates "remaining funding" based on raised funds vs. number of employees and their respective role's average salary? You could almost see it coming when a company is still in the early stages, probably not generating revenue, and burning up cash. The fact I even think about this means someone in the area of business finance thought of it a looong time ago... haha


Could probably build this with paid access to Crunchbase data set and LinkedIn headcount. Their roles, when advertised, should have (broadly defined) cash comp depending on state pay transparency laws. Cool idea.

Seriously though, if you're a business like https://simpleclosure.com/ you'd probably use this for prospecting. Recruiters too might pay for such a list to recruit from companies in peril ("motivated talent"). Lots of ways to potentially squeeze some fiat from this idea imho.


You're missing the revenue component if you do that.


If they indeed ran out of runway, then Airplane missed an opportunity for a memorable "our incredible journey" post.


usual caveat that fundraise announcements can happen anywhere from 1-18 months after the actual round was raised so dont read too much into the timing

but also linkedin says that had up to 50 employees. highly doubt they were each making like 500k/yr cash on average


> but also linkedin says that had up to 50 employees. highly doubt they were each making like 500k/yr cash on average

Cloud/servers/infra/where the bits live and move + people + misc biz expenses were assumed in my estimate.


if they were spending that much on cloud/servers/infra they wouldnt have a revenue problem... typically


They offered a nearly free runtime and free network ingress/egress. You’d only have to buy one $10 seat and use it for ETL to cost them a lot of money a month. No idea if anyone did that though.


most reasonable companies have limits to prevent abuse of that stuff, in the fine print. a professional company like airplane would not let that bankrupt them, this is rookie league


Probably a right punition for people thinking that they can be lazy and build their business critical apps on a random startup proprietary and closed source SaaS.

Not to forget again that the cloud is just someone else's computer...


The bank is just someone else's money, the grocery store is just someone else's food, the OS is just someone else's code.

I used to use that cloud quip, until I researched what IaaS is and accepted there can be benefits. And note, that quip is usually used for IaaS, not SaaS.

That all said... This seems like a really shitty rugpull by the company.


Not good examples IMHO. The bank is legally your money. The OS can be freely reinstalled without hassles.

As for stores, they all have the same way of purchasing stuff, and if they all shut down, society would collapse and you have bigger problems.


But does it matter - he said he's excited!


Excited the Airplane is not falling off the end of the runway..


More likely he is excited to cash out.


Well, it has been an Incredible Journey.

https://ourincrediblejourney.tumblr.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: