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

21–30 of 482 posts

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

#21

Post by gowld »

gregdoesit wrote: post #12
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…

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

> staff+ engineers, eng leadership,

How does this even exist at a company with essentially no revenue? This should be at most 1 person in "staff+ engineers, eng leadership"

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

#24

Post by axg11 »

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…

Amongst a sea of negatives, that they continued to share these numbers with employees is a positive mark for the culture at Fast. Sure, it's easy to say with hindsight that Fast employees should have seen the demise coming. On the other hand, they also watched one of the founders raise $100M+ from Stripe. Perhaps they thought the burn could continue and eventually the product would reach traction.

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

#25

Post by buf »

kache_ wrote: post #22
buf wrote: post #13

Wow, I make the same revenue as Fast as a one-man entrepreneur. It really amazes me sometimes the strategies of these heavily funded companies. Why pile on so much burn so quickly?

Time to ring up some VCs, buf xD

And end up like Fast?!

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

#26

Post by gowld »

> The mock-up of the spreadsheet people who received offers at Fast had access to. The numbers represent what a senior engineers with $220K in base salary, and 30,000 options saw as numbers on their potential compensation value.

The spreadsheet didn't even have a row for "might not be a huge success".

This company was red flags from the start. I can't imagine someone walking away from a $300+K FAANG job for $240K + obvious BS equity.

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

#27

Post by toomuchtodo »

tough wrote: post #9
edent wrote: post #3

Can someone explain what Fast's USP was? Every ecommerce platform I've used has a PayPal / Google Pay / Klarna button. I click it and my payment & shipping details are there. Seamless. So what problem was Fast trying to solve?

New klarna virtual cards for not needing ecommerce implementing financing directly is genius. I guess with nowadays infra as code for financing that makes sense in 2022

Affirm is doing the same [1]. Debit rails are just easier versus the integration schlep. If you're a fintech, you can do all sorts of cool presentation and product offerings using a virtual account attached to a deposit account (BNPL is one, as is a hybrid credit/deposit account). Debit/virtual card also empowers the consumer, as you're not beholden to the merchant or their gateway provider to support a specific fintech integration.

[1] https://www.affirm.com/debit

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

#28

Post by adamsmith143 »

AYBABTME wrote: post #18
adamsmith143 wrote: post #7

That Startups are fundamentally risky and despite all the talk on HN you are highly likely to spend years working in a high pace high stress environment for equity that will ultimately be worthless or at best match comp at FAANGs all while having questionable WLB.

But working at FAANG is not much fun. I think a mix of both startups and Big Tech leads to a happy life.

Well that's definitely subjective but in terms of Pay and WLB I think big tech beats startups generally

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

#29

Post by why-el »

This connects nicely with Dan's article from yesterday [1], if only tangentially. I think a good habit is to instill a mindset whereby there is a single metric for cost, possibly associated with your main product, and keep track of that cost as it relates to your infrastructure spending. I've seen it before work well. For instance, if you sell computers, the cost could be, we spend $100 on infrastructure per computer sold, and engineers can then argue for spending more effectively.

[1] https://news.ycombinator.com/item?id=30936189

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

#30

Post by nosianu »

xrd wrote: post #19
gregdoesit wrote: post #12

Earlier quoted context omitted.

Author here. I was wrong on this information and updated the article - got a correction since. L6 and above employees would receive this: staff+ engineers, eng leadership, sales etc. There are companies where this information does go out to all employees in the spirit of radical transparency. Skyscanner is an example where every day, every employee gets the full revenue breakdown. These numbers are also shown on moni…

That's really fascinating information. Dashboards are all the rage as a way to get teams aligned around "critical numbers" (the metrics that matter). But, if your dashboards start telling a story of impossibility, your best people are going to leave earlier rather than hang on. A definite downside to the dashboard cult.

Is it? Maybe it's good if the decision to abandon ship is distributed over more people?

It hinges on one thing that I don't know: How likely are already failing companies to recover? Probably with the added condition that incoming help is not foreseeable, because if it's failing but people know help is coming that takes away some of the negative signaling.

I suspect that most of the times struggling companies won't get better, or at beast will continue to struggle and never make it big.

If that is the case, it will be better for both parties, not just the employees but also for the founders, if the life of this failed attempt of a business is cut short. I know first hand that when you are heavily invested pulling the plug yourself is really hard. I have no data, but I would not be surprised if the problem of staying too long - for founders too - is larger than the opposite, pulling the plug too early. Not that the latter is easy to show, since even if you get a large sample, you will never know for certain for many of the data points what would have happened if the plug had not been pulled without parallel mirror universes.

Post reply on HN