Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

211–220 of 482 posts

Re: What software engineers can learn from the rapid collapse of Fast

#211

Post by hyperpallium2 »

mwcampbell wrote: post #34
lmeyerov wrote: post #31

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

I'm not familiar with the phrase "cockroach team" in this context, and the obvious web search didn't help. Can you please elaborate?

Look into the early history of Airbnb. They did anything to survive - even selling politician-themed breakfast cereal. Yes. pg exclaimed, you guys are like cockroaches, you just won't die.

Don't know if that's the origin, but hey it could be. Without the story, calling someone "cockroach" has unclear sentiments.

Re: What software engineers can learn from the rapid collapse of Fast

#212

Post by jimbokun »

PragmaticPulp wrote: post #6

> Tiny daily sales numbers which all employees received was the first such warning sign. Internally, Fast was transparent on sales. Every day, every employee would receive a sales summary email that listed the number of sales completed with Fast checkout, and the total sales amount. > Fast did less than $300K worth of sales and below $6K in revenue on most days from January 2022 to April 2022. There were days with ar…

By my back of the envelope calculations, they would need to raise about $10 million a month to sustain that burn rate.

Re: What software engineers can learn from the rapid collapse of Fast

#213

Post by suresk »

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

I've been in situations somewhat like this before, definitely not as extreme, but the same sort of overall feeling. Everything talked about in Slack/Email is super positive and highlights all the great things customers are saying, but the financial results tell a different story.

It definitely is hard to have conversations about what isn't going well, even though it doesn't have to be negative or gloomy. Often the disconnect in results is chalked up to external factors outside of your control, which is sort of depressing because if that is true then you can't do anything about it.

It's like when someone encounters a bug in the stuff they wrote and look every which way they can to blame it on the library, framework, compiler, etc.. - I'd rather have the bug be in code I wrote because then I can fix it easily. You can show someone simple data that shows a strategy isn't working, and then they'll spend a week torturing the data to come up with a contrived counter-explanation.

Ultimately, it is tough because part of doing a startup is remaining positive even in situations where it isn't warranted and there are times where the strategy may not be working out in the short term but needs more time to play out. Being unwilling to ever even entertain the idea that what you're doing isn't working seems like it might be problematic though.

Re: What software engineers can learn from the rapid collapse of Fast

#214

Post by hardwaresofton »

mwcampbell wrote: post #191
tomp wrote: post #186

Earlier quoted context omitted.

Even before using more servers, one should consider using (one) bigger server (and another as backup). Massive servers are laughably cheap these days. E.g. 16 cores, 128GB RAM is €112 from Hetzner.

Damn, wish those dedicated servers were available in Hetzner's US data center. As far as I'm aware, the closest thing to a competitor in the US is OVH, and the server you get for that price is about a quarter of the capacity. That's plenty for my little company, but still...

Same here -- I'm eagerly awaiting them having a dedicated server offering

In the meantime have you looked at leaseweb?

https://www.leaseweb.com/dedicated-servers#US

I'm planning on running nimbus web services[0] there and there are a few other smaller providers I have earmarked depending on how brave you are:

https://www.defendhosting.com/usa-unmanaged-servers/

https://cc.delimiter.com/cart/dedicated-servers/

https://greenserver.io

[0]: https://nimbusws.com

Re: What software engineers can learn from the rapid collapse of Fast

#215

Post by hibikir »

emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

Going after large enterprise sales is a well known trap, and it's just so easy for a startup to spin its wheels for months, and eventually years, and realize that all the efforts got nowhere. The first 1B+ seller is precisely the hardest: Even when you are a relatively well known company, you'll still see reticence in bids if they know you are going to be their biggest costumer by volume.

The companies I know that succeeded with that strategy either have great starting relationships with insiders in their first sales, and had contracts signed before committing to a big staff, or got into said companies when they were small: If one of your customers turns into a rocket ship and you are tied to their revenue stream, their growth is your enterprise-sized company.

Enterprise sales might not even be all that profitable when it's all said and done: How many other companies are going to try to bid on their business? With their large size, how good is their leverage to squeeze down the profits of the winning bid.

You might have a relatively unique product, the right connections, and end up being Palantir, but it's a very narrow road with steep cliffs everywhere.

Re: What software engineers can learn from the rapid collapse of Fast

#216

Post by klabb3 »

Animats wrote: post #62

"Most engineers joining didn't know much about why the one-click checkout industry has the potential of billions." So why isn't this a standard feature of every shopping cart program, including the cheap ones? The complicated part is that you need "undo", valid for a while after ordering. That's what makes one-click buy feel safe for customers. This complicates inventory management. But you really need "undo" for an…

> So why isn't this a standard feature of every shopping cart program, including the cheap ones?

I agree. It makes absolutely zero sense that an isolated feature constitutes the foundation of an entire company, much less a 400 people company.

I clearly don't understand VC logic.

Re: What software engineers can learn from the rapid collapse of Fast

#217

Post by mooreds »

lolsoftware wrote: post #33
mwcampbell wrote: post #20

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

Yes!

I've seen a few startups that seemed to overengineer things (or build custom solutions rather than use something off the shelf) in expectation of massive growth.

I also thought it might have been due to resume driven development and the need to keep engineers engaged so they didn't leave.

I've also seen successful startups with a monolithic rails or PHP application that ran on heroku with next to zero custom architecture components.

Re: What software engineers can learn from the rapid collapse of Fast

#218

Post by pyb »

maybetoofast wrote: post #207
emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

I joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

Re: What software engineers can learn from the rapid collapse of Fast

#219

Post by relaxing »

throwmeariver1 wrote: post #205
ushakov wrote: post #203

Earlier quoted context omitted.

> The company spent a lot of money on marketing events including sponsorship deals with the Tampa Bay Lightning and the rumored million dollar concert by the Chain Smokers here we go, this is late 90s all over again

You think we get parties with Kid Rock again?

These days? Sure, an appearance by Kid Rock is much more affordable.

Re: What software engineers can learn from the rapid collapse of Fast

#220

Post by nomel »

PragmaticPulp wrote: post #41
lmeyerov wrote: post #31

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

> We get job candidates with high competing offers for companies I know to be rotten inside, I fell for this trick once when I was younger, but never again. As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too! We had a competitor do something similar at a prior company. I would tell candidates that we can't m…

> find ways to pay well above market rate. You can have a fancy title, too!

On my way out of the first startup I worked for, there was an offer to double my pay! Nope!

Post reply on HN