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

411–420 of 482 posts

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

#411

Post by lupire »

JumpCrisscross wrote: post #392
b20000 wrote: post #312

Earlier quoted context omitted.

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

> we never raised any money Who? (Also, given an open market, as was the case when the Amazon patent expired in 2017, the company fundraises to scale will beat its more timid competitor. This is basic strategy.) If you were in a different industry…great execution in the wrong industry is as good as a Ferrari in a swamp. > all that matters is knowing people Sounds like you’ve been through some shit. I’m sorry for that…

FAST wasted $100M on nothing. That's not conservative.

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

#412

Post by plasticchris »

lupire wrote: post #410
cormacrelf wrote: post #373

Earlier quoted context omitted.

This whole thing is strange to me. It's targeted at software engineers, and the dominant theme is that you should be wary of toxic positivity and a number of specific indicators that you should be able to see from your desk as an engineer. The discussion in here is also focused on that. But if you are an early employee with equity, you are not just an engineer. You are, figuratively, a shareholder. One of the reasons…

The reason they give options is that giving out stock basically forces an early IPO due to the 500 employee rule.

I think options will trigger this as well, this is where the “double trigger” rsu came from.

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

#413

Post by lupire »

skeeter2020 wrote: post #308
lowkey_ wrote: post #228

Earlier quoted context omitted.

But didn't Bolt succeed (order of magnitudes more revenue) by taking those enterprise customers while Fast was only getting SMBs? I'm currently at a seed-stage startup with a few Fortune 500 companies as users. We're lucky to have a great sales team that can bring that business in. If we're solving a problem for them, they're willing to use us regardless of our size, though they do care about some small particular is…

I work for a competitor to Bolt (and Fast) though not in one-click checkout. To say "Bolt Succeeded" is premature IMO. The federated checkout space is very crowded, with razor-thin margins and huge competitors. If I was going to pick a winner it would be Apple or another org with their network and leverage. Bolt is definitely doing better than Fast ever did by several magnitudes, but still not profitable (though that…

How is Bolt more than just your browser's saved credit card feature?

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

#414

Post by lupire »

danielmarkbruce wrote: post #255
emgeee wrote: post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

An overly positive culture is default behavior for most startups. It does appear to be poisonous and there is nothing you can do about it. If you call people out on BS, you are painted as a negative person. Not sure there is a fix.

Most new businesses fail. Realists don't launch new businesses (unless they are spending other people's money).

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

#415

Post by lupire »

agilob wrote: post #354
teruakohatu wrote: post #309

Earlier quoted context omitted.

What is a time-windowed hash-map? Just a time based key-value store?

Yes, a hash map that expires objects and loads new KV when key isn't present inside https://github.com/google/guava/wiki/CachesExplained

No, it's a rolling buffer of last N hours/days of data, but compressed into a hash table of counters instead of a log array.

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

#416

Post by HideousKojima »

robot wrote: post #210

The article has good points but misses the actual answer in my view to "what software engineers can learn" or in fact anyone can learn from this. Don't join a company only because there is more money. If you don't know what one click checkout is or have any intellectual interest in it, but jump on it just because you can make more, you will be disappointed. This works the same way in everything in life. One must have…

I have very little interest in tax software, but my current and previous jobs are writing tax software (though I guess my previous job was technically tax software plus other internal tools for a local government). But for me the interest isn't in what the software I'm writing is for, it's in the interesting and unique problems I get to solve, even for something as boring as tax software.

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

#417

Post by bikamonki »

. And yet, every small business needed custom engineering work to be done, making integration slow. Several engineers mentioned how they did not understand how spending lots of engineering effort for each small client resulting in little revenue would result in building a company that could be worth $12B one day.

In other words: fast was not itself a one-click checkout product.

Two of my products failed for the same reason. These are high-touch sales in terms of the custom work that needs be done for every new client. I have also seen a product fail due to the high cost of providing tech support vs account revenue.

What seems odd in this case is that Stripe knows very well how a low-touch saas should work and yet they invested in Fast. Maybe they assumed client customization will eventually be solved with a handful of options that would fit most needs?

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

#418

Post by nowherebeen »

tuyiown wrote: post #370
im_down_w_otp wrote: post #272

Earlier quoted context omitted.

How on Earth did the company raise so much money with so few milestones of any kind being achieved?

Way too much VC money is not driven by business analysis, and influenced by FOMO, especially in big names circles. It's totally irresponsible.

I think a lot of egos are running the VC business than actual investment analyst.

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

#419

Post by brian_cunnie »

belval wrote: post #270
maybetoofast wrote: post #207

Earlier quoted context omitted.

I joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…

> we would have world-class catering for lunch every day

I'd like to point out that this is not the case for every Silicon Valley start-up: the three start-ups I worked at (CollabNet, Aeluros, Ardatech) were incredibly frugal with money (exception: salaries were competitive).

At one of the companies, the CEO and I took a trip to Safeway to buy soft drinks for customers. When we got back, I walked around the office telling everyone the soft drinks were _not_ for them, only for customers.

At another company, I had to make a compelling presentation to the CTO to buy a $1.5k printer. "The Linux workstations need a PostScript printer!" We bought the printer, but he didn't like parting with the money.

Being frugal doesn't guarantee success: my CollabNet stock was washed out in later rounds, Aeluros had a fair-to-middling exit to Broadcom, and Ardatech had a good exit to Google. But it's good to keep an eye on the money.

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

#420

Post by nowherebeen »

namdnay wrote: post #391
pyb wrote: post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

> I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers i'd say that if you plan on scaling, you need a bit of both. a lot of tricky scale/process/architecture questions have effectively been "solved" in big orgs, it's useful to have people who can bring this experience to take a completely random examples: setting up a performance improvement plan, p…

That’s the problem. They had 0 need of scaling. It’s premature optimization 101.
Post reply on HN