111–120 of 482 posts
Earlier quoted context omitted.
$100M is a lot less money today than it was in 2000 after factoring in inflation and low rates.
Yes, but also no. Per the CPI, for every $1 in 2000, you need $1.68 today. 1.68^1/22 - 1 is about 2.39%/year inflation. https://data.bls.gov/cgi-bin/cpicalc.pl?cost1=1&year1=200001...
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.
Earlier quoted context omitted.
Pretty sure the reason they caught that flak is because they chose to reinvent the wheel instead of do a normal thing that would work until later - they're on their what - third rewrite of that now? Tootally worth the time /s
I don't think that's a fair characterization of what happened. First, they scaled a simple solution for a long time and migrated away from it before it exploded spectacularly. I don't recall them explicitly saying how much time they spent on it, so how is it possibly to say whether it was worth the time or not? I also don't remember if it was here or on Twitter, but one of the engineers listed the many features they…
Earlier quoted context omitted.
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.…
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 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.
Earlier quoted context omitted.
I believe startups should implement levels once you hire 2 engineers. It's hard to retrofit a system, especially if you're trying to be thoughtful about any pay imbalances.
> startups should implement levels once you hire 2 engineers I think OP is cracking a joke about a $600k company having six levels of hierarchy.
- When you hire, you implicitly put people in a level which dictates what you're willing to pay them.
- People will always feel underpaid, and demand more $$. Without a system, you give them out arbitrarily.
- You now have enough people to add structure to the process. Do you base people's levels on their current salary? On their skill?
- What happens when people notice the discrepancy in pay or skill among a level? Especially if it's skewed by race, gender, etc?
I think you should have as many levels as pay-bands in your startup, which might be 6.
Wow, these numbers are like those from pets.com: > "During its first fiscal year (February to September 1999) Pets.com earned $619,000 in revenue, and spent $11.8 million on advertising." (Wikipedia) > "The company raised $82.5 million in a February 2000 IPO but filed for bankruptcy nine months later." (Investopedia) Fast rasied $102 million in capital and had $600k in revenue that year... Is Big Finance about to hit…
$100M is a lot less money today than it was in 2000 after factoring in inflation and low rates.
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…
And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.
So in my now close to 30 years of experience later, working on systems expected to run 24/7/365, I can't tell you what percentage of failures and outages were caused by the redundancy/fail-over/etc software and hardware layered into a system, but its definitely a very significant part of the problem. Frequently because its just that a "layer" someone bolted on, even if that layer was some software engineer designing for "web scale". All the edge cases are frequently not completely thought out, and when you hit one its a lot harder to recover, than simply restarting a single service running on a single server.
That Startups are fundamentally risky and despite all the talk on HN you are highly likely to spend years working in a high pace high stress environment for equity that will ultimately be worthless or at best match comp at FAANGs all while having questionable WLB.