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

231–240 of 482 posts

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

#231

Post by skrtskrt »

hibikir wrote: post #215
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…

Going after large enterprise sales is a well known trap, and it's just so easy for a startup to spin its wheels for months, and eventually years, and realize that all the efforts got nowhere. The first 1B+ seller is precisely the hardest: Even when you are a relatively well known company, you'll still see reticence in bids if they know you are going to be their biggest costumer by volume. The companies I know that su…

Yeah I’ve worked places where the product was clearly superior to competitors in every possible way, including price, but selling to anyone beyond a small business was still VERY tough for multitude of reasons.

You would have companies where you have existing relationships, they love what you offer, and really want to work with you, but the deal just gets delayed by some other priority or reality of their business. The solution they already have is good enough (even if it’s barely good enough), and sticking with it is not actively putting them out of business for the time being.

It’s just reality… just like VC investing, selling into 100 small companies and growing along with some of them is waaaaay more likely to pay off than landing one whale

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

#232

Post by JonChesterfield »

TuringNYC wrote: post #190
jakey_bakey wrote: post #114

Earlier quoted context omitted.

I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.

>> I find it absolutely crazy that companies do this. It has changed a bit, but a large part of it is due to HR policies around salary bands. You can have one person do 10x or 5x and another do 1/3x but their salaries are often max .5 factor apart. Ive been in situations where i'd rather reward (perhaps with a vest period) one person with 3x the salary and just skip all the inter-person communications bs, but HR make…

It strikes me as a fundamental mistake that HR are not responsible for the consequences of their policies. Failing to hire people leads fairly directly to failing to ship products, yet that doesn't appear to be attributed back to the team that insists they are all asking for above 'market rate'.

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

#233

Post by DevKoala »

pyb wrote: post #218
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…

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

Hear hear.

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

#234

Post by nomel »

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…

As a shopper, one click buttons make me so nervous whenever I see them on the page. It definitely distracts me from my shopping experience, with a region of the screen screaming "don't touch me!!!".

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

#235

Post by Sebguer »

betaby wrote: post #37

I've never heard about Fast before I read the article. I don't know whether I live in a bubble or SV lives in a bubble.

They've been notable recently mainly for controversies, especially on Tech twitter, due to discrimination lawsuits and just general toxicity: https://www.businessinsider.com/fast-gender-discrimination-l...

They were also notable on twitter / reddit occasionally for giving away very cheap / subsidized swag like $1 hoodies.

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

#236

Post by somehnacct3757 »

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…

If you're at a SaaS startup that tries to solve a churn or burn problem by moving upmarket, run.

It means your leadership can't think of a way to make the business work other than to get bigger checks from the same size customer base. "If only all our customers could pay us an extra zero!"

Moving upmarket doesn't work that way. They are totally different companies with purchase requirements and habits that will generate tons of work orthogonal to your core product. Spend a few quarters on compliance accreditations so you can tick boxes, multi-month sales conversations where you aren't even sure if you're just there to pressure the real Belle of their ball, etc.

If you can't do it small, you can't do it.

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

#237

Post by suresk »

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…

It's always funny to read about crazy overspending on infrastructure and I have a few funny stories myself, but this was far from their biggest problem. For one, we don't know how big those costs were or how much time it would take to wind some of it down.

I absolutely hate waste and was always proud of myself when I found ways to shave a thousand here and there off our AWS bill, but it was a bit depressing when I went through the thought exercise of "What would it be like for the company if I managed to get everything onto the AWS free tier?" And then compared that to what it would be like for the company if we found a way to make 1 or 2% more in revenue.

Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue.

(Although often reducing the size of your infra for other reasons - usually around complexity for ops or ease of development can also have the side benefit of reducing cost and it seems worthwhile in those cases.)

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

#238

Post by RobRivera »

Jasper_ wrote: post #200
robocat wrote: post #194

Earlier quoted context omitted.

> "planes with two engines have twice as many failures as single engine planes" There has to be a smart reply to that, like: 100% of pilots of single engine planes don’t make it home after a single engine failure. 100% of pilots of dual engine planes do make it home after a single engine failure.

Planes are natural gliders and you can recover from engine failure. It's not like they just fall out of the sky.

say for the zoomy lawn darts we call fighters.

pushes glasses

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

#240

Post by geoduck14 »

suresk wrote: post #237
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…

It's always funny to read about crazy overspending on infrastructure and I have a few funny stories myself, but this was far from their biggest problem. For one, we don't know how big those costs were or how much time it would take to wind some of it down. I absolutely hate waste and was always proud of myself when I found ways to shave a thousand here and there off our AWS bill, but it was a bit depressing when I we…

>Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue.

YES! This is VERY true

Post reply on HN