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

61–70 of 482 posts

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

#61

Post by tomrod »

nly wrote: post #49
photochemsyn wrote: post #44

Wow, these numbers are like those from pets.com: > "During its first fiscal year (February to September 1999) Pets.com earned $619,000 in revenue, and spent $11.8 million on advertising." (Wikipedia) > "The company raised $82.5 million in a February 2000 IPO but filed for bankruptcy nine months later." (Investopedia) Fast rasied $102 million in capital and had $600k in revenue that year... Is Big Finance about to hit…

$100M is a lot less money today than it was in 2000 after factoring in inflation and low rates.

Yes, but also no.

Per the CPI, for every $1 in 2000, you need $1.68 today. 1.68^1/22 - 1 is about 2.39%/year inflation.

https://data.bls.gov/cgi-bin/cpicalc.pl?cost1=1&year1=200001...

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

#62

Post by Animats »

"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 hour or so after ordering.

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

#64

Post by 0xJRS »

davidkuennen wrote: post #51

Holy shit. How do you even spend 10M/Month?

It seems very hard to do but I worked at a startup in the early 2010s and we were spending >500k/m. We had ~25 employees, 7 of them execs, all buying new homes and cars, meanwhile we had 1 single paying customer bringing in 10k/m. I told some of my close colleagues that we probably had 6-12 months left when I put in my resignation.

12 months later they laid off 10 of the 12 remaining engineers.

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

#65

Post by odonnellryan »

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…

Lots of sites do not have a good undo for orders. I ordered from remarkable and their solution was to deny the package...

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

#66

Post by shagie »

davidkuennen wrote: post #51

Holy shit. How do you even spend 10M/Month?

> For senior software engineers, Fast offered $200-240K/year in base salaries

Lets put everyone there. $20k/month.

> On Monday, 4th April, Fast laid off all of its workforce of about 450 employees, of which about 150 were software engineers.

That 150 at $20k/month is $3M by itself.

The other 300... if they were paid half of that would easily be another $3M.

I'm certain there are other costs - but its easy to point to a "if they were paying that much, this many employees represents this much per month" that is a sizable fraction of that $10M/month.

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

#67

Post by diehunde »

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?

Maybe they work at Cockroach Labs

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

#68

Post by randmeerkat »

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.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

More like, sounds like management was trying to get as much money as quickly as they could from their VCs before it all imploded. The engineers aren’t at fault that management didn’t have a real product or vision.

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

#69

Post by hobs »

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.

Pretty sure the reason they caught that flak is because they chose to reinvent the wheel instead of do a normal thing that would work until later - they're on their what - third rewrite of that now?

Tootally worth the time /s

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

#70

Post by lordnacho »

davidkuennen wrote: post #51

Holy shit. How do you even spend 10M/Month?

Makes no sense at all. Presumably whoever is allowing people to be hired knows what the revenue figures are?

I suppose it's possible they thought there was some sort of dam holding back business, which was about to burst, thus requiring loads of staff to deal with.

But most people would just say "we'll cross that bridge when we get there" and allow a bit of queuing up of customers, rather than somehow hiring and training a bunch of people in anticipation.

Post reply on HN