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

81–90 of 482 posts

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

#81

Post by jollybean »

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…

That's the magic question.

1) Carts are slow to evolve but they will.

2) Bolt/Fast contain user based information, consumed from their use on other sites. So there's a 'network effect'. If they've shopped at ABC.com before your store, then you already have their CC data ready to go in their car. Sort of like Single Sign On but for carts.

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

#83

Post by gregdoesit »

lupire wrote: post #40
gregdoesit wrote: post #32

Earlier quoted context omitted.

This is a hallmark of a scaleup which assumes it will become a massive company in a short amount of time, and sets up its structure accordingly. There are times when a gamble like this pays off. Take how Uber built their organization and systems similar to how Google did it, even when they were smaller. In the case of Uber, their approach, you could argue, paid off in the sense that Uber did get traffic that would ha…

Uber had revenue and millions of customers begging for someone to offer the service. Google did not have "staff+" when it was starting out. It had founders and a couple of hires.

Great points on both. Uber, indeed, did not have engineering levels beyond senior engineer until year 2 or 3 as far as I know (I joined later, but talked with several early engineers while there).

I was trying to play devil's advocate but I have to agree that pre-product-market-fit, these levels are likely an overkill and distract from the real problem: validating product-market fit.

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

#84

Post by asadlionpk »

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're a cockroach team

is this a reference to http://paulgraham.com/guidetoinvestors.html#:~:text=nuclear%...

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

#85

Post by sciurus »

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/

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

#86

Post by munificent »

Jemaclus wrote: post #36
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're a cockroach team I think I know what you mean by this, but I'm not sure. Could you elaborate on what this means? Thanks in advance. :)

I infer that it means "small and hard to kill".

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

#88

Post by lolsoftware »

hobs wrote: post #69
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.

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

I don't think that's a fair characterization of what happened. First, they scaled a simple solution for a long time and migrated away from it before it exploded spectacularly. I don't recall them explicitly saying how much time they spent on it, so how is it possibly to say whether it was worth the time or not? I also don't remember if it was here or on Twitter, but one of the engineers listed the many features they built and shipped _instead_ messing with their database. I'd say that was a good business decision - they got more features to their customers sooner and dealt with a scaling issue before it impacted customers.

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

#89

Post by xen0 »

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.

I wonder, how many engineers had full time jobs just developing and maintaining the various integrations with all their small clients?
Post reply on HN