Back of torn envelope calculation: 450 staff, 150 engineers = 300 managers? $600k revenue in 2021 => barely paid for their salaries at $200k each. What were they really doing? Going on junkets to Florida - yeah, that'll generate more revenue.
What software engineers can learn from the rapid collapse of Fast
271–280 of 482 posts
Re: What software engineers can learn from the rapid collapse of Fast
#272Earlier 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…
How on Earth did the company raise so much money with so few milestones of any kind being achieved?
Re: What software engineers can learn from the rapid collapse of Fast
#273Earlier quoted context omitted.
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…
> I wonder when the music stops. Who cares? Champagne on the Concord, and let's order a bunch of Starfire servers from Sun Microsystems!
> let's order a bunch of Starfire servers from Sun Microsystems!
I wonder if any doomed startups will order a rack from Oxide Computer. I hope Oxide's primary customer base is established companies that actually need serious efficiency at scale.
Re: What software engineers can learn from the rapid collapse of Fast
#274Earlier 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…
Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.
Or inexperienced startup engineers, given the nature of the name
Re: What software engineers can learn from the rapid collapse of Fast
#275"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.
PayPal and (Amazon) have way more customers and their data ready to go.
I don’t think one click buy is that useful for smaller sites (something like Apple Pay is much more valuable as the customer doesn’t have to think about a bunch of details).
Re: What software engineers can learn from the rapid collapse of Fast
#276Earlier quoted context omitted.
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…
How on Earth did the company raise so much money with so few milestones of any kind being achieved?
A well known name was attached and it was at the peak of the AI craze.
Re: What software engineers can learn from the rapid collapse of Fast
#277Earlier quoted context omitted.
There is a pretty good reason. If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. So the choice in many cases is big tech engineer or failed startup engineer. It's not clear which is better, it is clear (ish) which seems better.
This is not true at all. A lot of people In BigTech companies boast of passing a tough interview as their biggest accomplishment and beyond that haven’t really done much. Meanwhile, good startup engineers are used to learning new technologies quick, can work across the full stack, can own all aspects of their app/feature, work without much direction, never mind a formal spec, and generally are used to solve problems…
You've compared the worst big tech engineers with the best startup engineers. Those are rarely the choices faced.
Re: What software engineers can learn from the rapid collapse of Fast
#278Earlier quoted context omitted.
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.
Iirc Netflix is actually pretty well distributed because they now have edge devices in CDNs throughout the world.
Re: What software engineers can learn from the rapid collapse of Fast
#279Earlier quoted context omitted.
> 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.
Which of course it isn't, if you or your coworkers are dreading that 'they' will find out you're happily using Postgres...
Re: What software engineers can learn from the rapid collapse of Fast
#280Earlier quoted context omitted.
If you want to use a traditional credit card (inside of Paypal or GPay), your options are currently limited. Shopify has the best implementation of this tech with ShopPay ... if you pay at any Shopify merchant, you have the option for Shopify to remember your digits. This streamlines checkout to a click or two. That's the big USP of models like this - speed of checkout.
How are options limited by PayPal and GPay? What is a "traditional credit card"?
I assume it means paying he merchant directly with the credit card instead of paying PayPal to pay the merchant.