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

441–450 of 482 posts

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

#441

Post by alecbz »

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.

TIL it's actually 2000 shareholders as of 2012. https://www.investopedia.com/terms/5/500-shareholder-thresho...

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

#442

Post by samhw »

lupire wrote: post #411
JumpCrisscross wrote: post #392

Earlier quoted context omitted.

> 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.

I don't know why on earth this is downvoted. You're 100% correct and I'm bewildered that this 'conservative' trope is prevailing in the thread. Both companies spent functionally the same amount of money, and both maximised different terms of the [customer count]*[customer revenue] equation.

Fast made what was manifestly the wrong decision, both in hindsight and in foresight (I'm happy to post my WhatsApp screencaps from a year and a half ago when I was exploring starting a co in that space). It's not possible to build a hands-off 'platform' like Stripe in that space - integrations are complex, and so integrating a large number of small clients predictably bogged them down till they ran out of money.

(That's not the only reason, I'm sure. It was also a shitty implementation of one-click checkout: most saliently, it wasn't one click. Anyone who actually tried Fast at the time - and I & my prospective cofounder shared the few tiny client websites either of us found like they were rare gems - could see that it was a terrible implementation, in a space where UX is literally the entire game. Many actually did, e.g. this guy from back then: https://chrisfrantz.com/checking-in-on-fast/)

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

#443

Post by nemo44x »

adamsmith143 wrote: post #438
nemo44x wrote: post #409

Earlier quoted context omitted.

Correct. I’d suggest series b. Getting past a is a huge leap but you still have risk and upside.

Right but I think even with "Successful" exits your equity will most likely just get you back to level if you had instead spent the time at Google e.g.

Over a 25 year career, possibly. Especially the last 20 years as Google stock has performed so well!

Saying that, I've had some jackpots where there's no way Google compensation would have come close in the same window (couple million a year over a 4 or 5 years, for example). But other periods where it wasn't as good too.

Also, not everyone wants to (or can) work at Google. I personally enjoy building startups and everything that comes with it.

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

#444

Post by myrandomcomment »

mwcampbell wrote: post #322
myrandomcomment wrote: post #314

Earlier quoted context omitted.

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted t…

> Not something we could fix by tossing HW at the issue. I'm curious to learn why, if there's any more you can share. What about vertical scaling, i.e. bigger machines instead of more of them? Can't that go pretty far?

Shipping unit was a VM to a customer. Tossing more CPU & RAM at the VM would hit general issues of how VMware allocates CPU to a guest. Within the VM we had containers for each sub-unit of the tool. For some part of the system we made the deployment model more than one VM, distributing more containers to the other VMs. However for a key part of the design there was an in-memory DB and we just it the scale limits of the number of elements that could be handled that way without a rethink of how and what we stored.

For everyone that will say "well why..."

1. real products need a generally available shipping unit (SKU) when your customers are enterprise / telco types.

2. for item 1, what is the lowest common thing this type of customer would take - a VM they can run on their existing virtualization setups. the reality of K8s, containers in this type of customers at that point was near zero.

3. there was thoughts about a SKU of a HW appliance, ie, beefy server and just toss CPU/RAM in it and ship that. shipping some stupid HW appliance that we controlled would just be a distraction and a waste of money also requiring 2 shipping artifacts, 2 test setups, etc. not to mention the need to sort for support for HW failure (you can contract with Dell for example to have them label their Kit as your appliance).

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

#445

Post by esprehn »

gumby wrote: post #341
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.

It’s a kind of cargo cult, cf the post “you aren’t google”. The kinds of people who succeed at FAANG (MANGA?) are used to a lot of infrastructure and are (at google in particular) mostly incented to ship rev 0, not build a sustainable system. That’s a gross generalization, but gives you the flavor. I couldn’t do what they do (huge budget, low incrementalism) and would hate the environment. But they can’t do what I do…

My experience of Google is very much incrementalism and long term sustainability. Very few things at Google are built "new", it's tons of cobbling together systems that already existed and making small adjustments and optimizations to them.

There's a big difference between the product strategy side (v0 of N different chat products) and the tech side which is that all those products are made of many of the same components arranged differently.

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

#446

Post by alecbz »

plasticchris wrote: post #412
lupire wrote: post #410

Earlier quoted context omitted.

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.

As in, if a company as 500 (now 2000 I think) options-holders, the SEC will start regulating them as if they're public? I don't think that's true?

Double-trigger RSUs are AFAIK just a way to avoid paying taxes on illiquid assets. The reason to shift from options to RSUs at all is (I think) that once the company's FMV gets high enough, the strike price and taxes due for the options will be so high that employees won't be able to afford paying them if they leave the company.

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

#447

Post by samhw »

lupire wrote: post #413
skeeter2020 wrote: post #308

Earlier quoted context omitted.

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?

I was going to start a business in this space, and I can sum it up as broadly this:

- It saves all the details needed for 1-click, not only your card (which is just PayPal). So: shipping address, name, possibly even 'pre-done' age or fraud checks, etc.

- It 'maps to' the business's API far better than a browser's autofill can do, which only has some random HTML tags and a helluva lot of guessing. (In other words, users won't have to keep filling in the, like, 4 out of 9 inputs that it didn't understand.) Your advantage is that the merchant itself does the integration work themselves - though ideally your API/SDK will make that as easy as possible.

(Essentially, it's just: "user has a third-party cookie for your site, comparable to SSO, and you charge their saved details and call the merchant's API on the backend [or, for small businesses, a Shopify integration or whatever fresh hell the Fast engineers must've gone through]".)

It's an enormous potential market, though that's also true of the shipping industry and it doesn't guarantee big margins. I'm interested to see what comes of it all. I expect something boring like "Yeah, eventually [company X] got big enough, that's why Apple released the Apple Pay Checkout Fields API for JS".

As a footnote: Amazon has actually offered this as a service for ages, which I know because of the precisely one website I used which happened to offer it. If it weren't for the terrible antediluvian UX and the lack of any evident marketing, it probably wouldn't have been such an open goal for these startups. Here, this is what Fast was trying to sell a shittier version of, without a user base: https://pay.amazon.com/what-is-amazon-pay

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

#448

Post by hu3 »

kortilla wrote: post #372
dmje wrote: post #338

Earlier quoted context omitted.

> We have a few other systemic issues I’d like to see solved first Insane levels of inequality is what’s on my list

Do you know what the average salary is in the Bay Area? You’re completely out of touch if you think $250k is “insane inequality”. Take a look through the salaries paid for working at public transit there (BART): https://www.bart.gov/sites/default/files/docs/Salary%20Sched...

Bay Area is an exception on it's own. I think that link proves OP's point.

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

#449

Post by samhw »

ec109685 wrote: post #283
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…

What I couldn’t understand was that there were times where something like ApplePay was a clearly superior way to pay. E.g. JavaScript says the user has it configured and able to make payments, so one click payments were actually possible. At least publicly, Fast never addressed this, and insisted on requiring the user to log into Fast to make a payment even when it was a worse option. Browsers like Safari are explici…

I briefly made an MVP of 'basically Fast', and had to deal with mobile Safari, so I can tell you (hell, I can give you the code if you want it). We had to load our own site in a zero-sized iframe, at a specific endpoint which ran a script that read the cookies and sent them over the Window.postMessage API to the merchant page, where our JS was running and intercepted the cookie contents. But that was an MVP, and I was uncomfortable about the security implications even so - not sure how Fast's engineers hacked it together, if they even did.

The two of us ditched it when we realised how inhospitable the economics were, but even then we knew Fast's shitty play was bound to fail, and I heard the news from my prospective cofounder sending me a text ("we called it!") when it happened...

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

#450

Post by tomatowurst »

nailer wrote: post #427
tomatowurst wrote: post #227

Earlier quoted context omitted.

Very good point and you are not alone seeing the deja vu Remember beanie babies? We call them NFTs today. Remember HYIP and e-gold? We call them cryptocurrencies now. The point is that crowd behavior, especially markets driven by envy & greed, lead to the same outcome. every. single. time. this is why guys like Warren Buffett and Charlie Munger keep making money.

Beanie babies aren’t scarce and can only be produced by a single company.

neither is right clicking on a jpeg and saving it
Post reply on HN