131–140 of 482 posts
"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…
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.
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…
Earlier quoted context omitted.
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 yea…
Cost can be a difficult problem to solve! I've been working on a project for about six months trying to identify just how much it costs to deliver a unit of the thing we sell. There's just so much variability, one customer might have widgets that are 40kb in size and rarely ever run widget analytics workloads, while another customer has 40mb widgets and can't stop looking at them.
I feel for the whole "how do customers use the application" thing too. Product analytics at most places seems to be a concern long after features are developed.
"So how many customers have been using that feature we spent two years and $20MM developing?"
"Good question."
"Soooo, mywittyname, can you figure out how many people at companies with over 200 seats look at dog pictures after opening an email with a 'C' in the title?"
Earlier quoted context omitted.
Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.
Even startups benefit from job titles and hierarchy. Even startup employees benefit from a visible promotion path. Remember, they had hundreds of employees. Not just a couple people in a small office somewhere. Most likely, the levels corresponded to pay bands and helped determine where people fit into the seniority hierarchy (such as determining who receives sensitive daily information updates)
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 hope this problem doesn't exist at startups but I've seen it at entrenched institutions any number of time: 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. And the only way to use Postgres in this situation is if they don't know you're running it. Which puts you in the uncomfortable situation of wanting to say, "But Or…
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 choice after-the-fact is more sensible. Hindsight is always 20/20.
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.
Tailscale's "database from 2022" is neither here nor there. What you should do in this situation is use the most boring tech, such as PostgreSQL with a simple HA setup. Thus avoiding the "play with nifty toys" trap and maximizing the chance of making appropriate choices.
Massive spending of VC investment money on offices, a sales team, engineers, and a data center and servers to meet their expected (hoped-for) scale (there was no cloud then).
No large clients on the platform. Not a lot of small clients either, TBH.
One day out of the blue over half the company was let go. Some effort to downsize and retool, but it seemed perfunctory. All the rest of the staff was let go after another couple of months.
If you have no customers, you have no business.
Earlier quoted context omitted.
> 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 yea…
> We spent a relatively large portion of our revenue running very expensive servers to respond instantly to searches that no-one ever performed. The last 7 years of my life as an SRE. It's maddening.
It was the pet project of another team-lead, that no-one else wanted. Group decision making is bizarre.