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

241–250 of 482 posts

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

#241

Post by Apocryphon »

RC_ITR wrote: post #209
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

This is such a revealing comment and here's why: The reason late 90's start-ups invested the way they did is because they had no meaningful way to track the effectiveness of their ads, much less the payback. A Super Bowl ad for Pets.com seems fine if you can (more or less) guess that it adds a bunch of customers. Since then, start-ups have built a bunch of tools to track customer acquisition costs and paybacks in a p…

The music stops when the Fed tells it to. When interest rates rise appreciably.

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

#242

Post by CTmystery »

manesioz wrote: post #110

> 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

I'm shocked to learn that people with money funded another charlatan to the tune of $120M /s

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

#243

Post by Aeolun »

lupire wrote: post #175
lolsoftware wrote: post #33

Earlier quoted context omitted.

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.

> The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. I've seen this repeated on HN, but never saw the alleged flak.

It’s a post from around a week ago. They went from embedded JSON, to something else (equally crazy), to embedded JSON again. Lots of laughs were had (and a lot of, just use postgres).

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

#244

Post by zerocrates »

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…

I wonder just how much difference it makes that all this wacky startup action is private equity (writ large) rather than the public markets. Seems like... maybe a lot?

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

#245

Post by erikerikson »

hn_user82179 wrote: post #192
mwcampbell wrote: post #179

Earlier quoted context omitted.

Perhaps the thinking is that it's easier to hire multiple good-enough programmers to get dependable productivity, and to replace one if something goes wrong. In the extreme case, if a company has one programmer who is very good when they're working at peak productivity, but then they have a period of low productivity for whatever reason, that company is in trouble. I've been that person.

Additionally, it's a bigger loss felt when that person leaves.

And most companies can't seem but try to run them off.

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

#246

Post by Aeolun »

zozbot234 wrote: post #137
hinkley wrote: post #47

Earlier quoted context omitted.

I would hope this problem doesn't exist at startups but I've seen it at entrenched institutions any number of time: If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product. And the only way to use Postgres in this situation is if they don't know you're running it. Which puts you in the uncomfortable situation of wanting to say, "But Or…

> If your boss's boss or peers signed a contract for $1m a year from Oracle, you're going to use Oracle even if Postgres is a better product. What you'd do in that situation is make the best of that $1M contract you're stuck with anyway, while being flexible enough to migrate away from that solution when it actually makes sense to do so. Just because you've made a huge mistake doesn't mean that making a different cho…

Only if your $1M solution is already integrated.

Otherwise it’s just a sunk cost fallacy.

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

#247

Post by mylons »

ammanley wrote: post #224
mylons wrote: post #133

Earlier quoted context omitted.

this sounds like Ridgeline, a startup most have never heard of, founded by the founder of Workday and some of its early employees.

I have actually heard of this startup amazingly, as well as the founder, but I wasn't aware it was/is? as much of a s.show that the article portrays at Fast. Do you have any context you might be willing to share, I am genuinely curious.

bizarre tech decisions have led to insane costs with 0 customers. launch is about 2 years behind. having a lot of trouble hiring senior engineers, when they do they don't listen to them. they have a strange platform that every product team must use. tech leadership has never launched a successful startup before. they have over 300 employees, maybe 400 now. 4 levels of management already, and a _lot_ of them. it's independently funded for now, and has the potential to keep on going like this as long as Dave D. doesn't pull the plug.

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

#248

Post by JonChesterfield »

bogwog wrote: post #154
tlogan wrote: post #149

I never heard about Fast - till now. So my opinion is that they failed in advertising. Maybe they spent too much on engineering but definitely not enough on advertising.

When I read the title, I thought this article was about Netflix's speed test website fast.com, and thought they were having some catastrophic outage or something.

Does Netflix have outages? Searching found me suspicious sounding websites for querying whether it's currently down and a story from 2017 about AWS falling over creating a transient slowdown without loss of service.

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

#249

Post by Aeolun »

ben7799 wrote: post #104
EinsDueTresFour wrote: post #45

Earlier quoted context omitted.

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…

Well, they had 150 engineers sitting around for a product that required at max 3. Need to give them something to do to justify those 300k salaries.
Post reply on HN