What software engineers can learn from the rapid collapse of Fast • Hacker News Board

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

#101

Post by nonameiguess » Thu, Apr 07, 2022, 8:36 PM UTC

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.

Staying employed for another few decades without losing seniority in an industry that expects you to stay current on all of the latest hottest fads is a problem the engineers actually had.

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

#102

Post by [deleted] » Thu, Apr 07, 2022, 8:38 PM UTC

shagie wrote: post #66

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…

[deleted]

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

#103

Post by why-el » Thu, Apr 07, 2022, 8:38 PM UTC

sciurus wrote: post #85

why-el wrote: post #29

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…

Will Larson had a good post on this recently- https://infraeng.dev/efficiency/

Wonderful, thanks for sharing.

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

#104

Post by ben7799 » Thu, Apr 07, 2022, 8:38 PM UTC

EinsDueTresFour wrote: post #45

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…

I would add that the "Sales vs engineering and sales winning" would be a very relevant warning also: > [sales] signed up a large number of smaller businesses on the platform. [...] However, integrating these smaller businesses was challenging thanks to several customizations needed for each new customer. The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenanc…

Management probably really screwed this up if they were really only making $600k/yr.

Places I've worked yearly contracts for B2B have been in the $100k-$5M/yr range.

The customers paying $100k/yr barely get any integrations and feature changes... they go for the ride. The customers paying $1M+/yr get features on the double.

If Fast was doing integrations and customization for customers that were paying $1000 or less a year something was very very wrong.

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

#105

Post by coldcode » Thu, Apr 07, 2022, 8:39 PM UTC

I worked at a consulting firm in the late 90's (right before Dotcom collapse) and we got a new CFO who bragged we were all going to millionaires shortly. Most of us engineers thought he was nuts as consulting firms are not exactly money engines. We survived past the March cliff in 2001 but in mid summer we died at 4:30PM with 20 minutes notice to leave the office before the locks were changed. I never trusted a CFO new hire again...

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

#106

Post by mcphage » Thu, Apr 07, 2022, 8:42 PM UTC

mwcampbell wrote: post #50

jonas21 wrote: post #42

Earlier quoted context omitted.

It would not have made a difference. Maybe they'd be losing $9.9M a month instead of $10M a month.

Sure, their primary problem was extravagant hiring, but I think this is still an important warning for developers working in fledgling companies that are appropriately cautious on the hiring side.

> Sure, their primary problem was extravagant hiring

I think their primary problem was a huge valuation—with correspondingly huge expectations—but no real revenue. If you're pulling in $600K revenue, but valued at $500M... you're gonna have a bad time.

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

#107

Post by ben7799 » Thu, Apr 07, 2022, 8:42 PM UTC

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…

This does seem like a 1990s story.

I'm just barely young enough to have missed it. Friends who quit school early were in on it.

I don't know if this was the case at Fast but in a lot of cases back in the 1990s a lot of the engineers knew everything was screwed up.. and they just didn't care, the money was good while it lasted.

The experience almost always helped people get ahead, no one ever gets punished for doing good work at a company that fails due to bad management and investor decisions.

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

#108

Post by JumpCrisscross » Thu, Apr 07, 2022, 8:43 PM UTC

deepinsand wrote: post #92

encoderer wrote: post #17

Earlier quoted context omitted.

Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.

I believe startups should implement levels once you hire 2 engineers. It's hard to retrofit a system, especially if you're trying to be thoughtful about any pay imbalances.

> startups should implement levels once you hire 2 engineers

I think OP is cracking a joke about a $600k company having six levels of hierarchy.

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

#109

Post by jjav » Thu, Apr 07, 2022, 8:46 PM UTC

Spivak wrote: post #35

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…

And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.

This is a big lesson to heed. Sure, sometimes a startup really needs extravagantly scalable infrastructure. For the 99.9% of startup, no, you don't.

So the odds are you don't. Keep it very simple, very small. I can't highlight this enough. A few boxes will get you very far. If you ever actually hit the limits, throw a big party to celebrate success and only then start to think about making your infrastructure a bit (just a bit) more complex.

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

#110

Post by manesioz » Thu, Apr 07, 2022, 8:47 PM UTC

> I found some unsettling information about the founder of Fast, Dominic Holland.

This thread [1] touches on what some of that stuff probably was. Sounds like the CEO was a charismatic scammer.

[1]: https://nitter.net/jack_raines/status/1511737489190494208