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

71–80 of 482 posts

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

#71

Post by vosper »

EinsDueTresFour wrote: post #45
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…

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…

> The ratio of revenue per each small customer vs the total cost of integration (and very likely on-going maintenance) was probably at least an amber flag somewhere for those who had visibility of it.

At the last company I worked at (won't call them a startup, just a 10-year old small business that somehow kept raising funding but has never made a profit) I was astonished to learn from a new CPO that in our tenth year we didn't know if we were making money from a customer.

We had no idea how individual customers used the application, which was very data intensive, or what that was costing us. The information was there, but no-one ever looked. Every sale was considered a success, even if it turned out to cost us 3x in data costs and customer support. Often customer support alone would make a sale into a loss.

We spent a relatively large portion of our revenue running very expensive servers to respond instantly to searches that no-one ever performed. I created detailed monitoring to show this. I talked about them to everyone, including Product and the CEO. No-one disputed those facts. But instead we had several people essentially dedicated to downsizing application servers and deleting unused S3 buckets, trimming three zeros a month when we could have trimmed five.

I have learned not to assume that warnings are visible, that people pay attention to them if they are visible, or that anyone cares.

They're still circling the drain, still raising money (somehow!) and I doubt anything's changed.

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

#73

Post by alex_c »

mwcampbell wrote: post #34
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…

I'm not familiar with the phrase "cockroach team" in this context, and the obvious web search didn't help. Can you please elaborate?

I'm not the op and this is the first time I've seen someone else use the term, but I've used it too. Aspirationally - small and impossible to kill. While a unicorn's goal might be growth at all costs (with associated high chance of failure), our goal is to survive anything that might get thrown our way.

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

#74

Post by rockostrich »

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…

This is pretty hilarious to read.

I did an interview screen with them at the end of last year for a data engineering position (former coworker was high up on the design side of things and he gave a referral). The first bit of the technical question was just "write a SQL query" and boiled down to doing a group by, count, and limit. The second was something like "what if we needed to return this query from a distributed system without going to the database?" without much context.

As any sane interviewer would do, I asked for context around scale, infrastructure, and what "without going to the database" even meant. The interviewer just reiterated the question. I started talking about different approaches depending on context and all the interviewer did was tell me to program a solution. Turns out all he wanted was a time-windowed hash-map to cache values and the fact that it's a distributed system didn't matter at all.

I think that just about sums up their approach to engineering solutions.

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

#75

Post by bprater »

edent wrote: post #3

Can someone explain what Fast's USP was? Every ecommerce platform I've used has a PayPal / Google Pay / Klarna button. I click it and my payment & shipping details are there. Seamless. So what problem was Fast trying to solve?

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.

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

#76

Post by fourseventy »

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…

I run a company in the e-commerce tech space. We handle ~1M requests per day and run it all on a few medium sized VMs on Google cloud for like $1k/mo.

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

#78

Post by meetups323 »

PragmaticPulp wrote: post #41
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 get job candidates with high competing offers for companies I know to be rotten inside, I fell for this trick once when I was younger, but never again. As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too! We had a competitor do something similar at a prior company. I would tell candidates that we can't m…

May help explain some Meta offers I've seen... 2 years out of college? Sure, come as a Senior! That's not enough? Principal it is!

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

#79

Post by jollybean »

mwcampbell wrote: post #34
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…

I'm not familiar with the phrase "cockroach team" in this context, and the obvious web search didn't help. Can you please elaborate?

small, surviving on crumbs.

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

#80

Post by enra »

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.

> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work.

Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction. Senior leadership and founders are likely busy hiring more folks and potentially trying to sort through the chaos described before.

IMO, pre-product market fit company shouldn't have 500 employees, maybe not even 10. These things don't become easier with more people, usually everything gets harder and slow. You also shouldn't have massive marketing or sales force before you actually have product to sell and have figured out your sales motion.

It seemed that Fast was just trying to shortcut their way to be the next Stripe by hiring people instead of actually working on the fundamentals like the product and business.

Post reply on HN