4 ms·

It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite

by adrr 4y ago

It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite. I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them. Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations.

klabb3 4y ago
I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare. You should make architectural choices that CAN be scaled within reason, on demand and ideally incrementally. That doesn’t mean you need to build your app on Kubernetes and automate welcome emails, surveys, metrics, A/B testing etc. But you probably shouldn’t build on top of fundamentally non-scalable systems either. This is provided you’re in an environment that can reasonably scale to 1M users or whatever, which isn’t true for all domains. Say B2B where that last B is only 10000 people world wide.
- what-the-grump 4y ago
  It’s difficult to explain to people what you said without the experience of living in the failures of early optimization. K8s from day one, a-b testing, programmatic quality control without any paying clients on the product, scrum master and a PM and a product owner for 5 devs! Whole thing feel like a Ponzi scheme to keep overseas staff employed, perpetrated by the overseas development shop. Unless you built something absolutely atrocious, scaling it vs getting it ‘right’ or ‘right enough’, is trivial. You couldn’t sign up to Facebook if you weren’t a college student. Chatgpt overloads daily so what? When your app becomes necessary to enough people, bring in your k8s evangelists and shove into x cloud provider. But by god it doesn’t take 30 people to write a marketable mvp.
  - klabb3 4y ago
    Couldn’t agree more.
  - deleted 4y ago
    [deleted]
  - adrr 4y ago
    Maybe I had the fortunate luck that we never had issues of finding market fit. We also had lots of investment outside of software dev. Fintech for example requires significant investment in compliance(eg: kyc). Chatgpt doesn’t have competitors. Customers can’t go elsewhere. Twitter had the same protection when they launched, there wasn’t a short form social network so they could have full day outages. Friendster would be the opposite, when they closed signups, customers just went to MySpace. Scale goes beyond the ability to support traffic. It also means efficiently handle data/traffic. Heap is a good example, great product but they haven’t figured out to provide that level of analytics without significant costs which are passed on to the customer.
  - vbezhenar 4y ago
    What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence.
    - doteka 4y ago
      Nah, statements like the above are a sign of lack of experience, missing business understanding and/or hubris.
    - lelanthran 4y ago
      > What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence. Everywhere? Sounds like you're cargo culting. There's a use-case for it, and that use-case is when your load is so high you need the orchestration.
      - vbezhenar 4y ago
jdsully 4y ago
Post product market fit scalability is critical. But a lot of effort is spent on things that will never get traction in startup land. Before you get traction the times at bat is the more important metric.
SkyPuncher 4y ago
In you're case, you clearly already had Product-Market Fit. Most startups do not. It's far more valuable to build quick than it is to build for scale until you know PMF.
lelanthran 4y ago
> It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite. Depends. No one at a unicorn says that, but I've seen plenty of startups that. The unicorn is the outlier, not the rule. > I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them. Were they still in business at the end of all this? Because it turned out you made a bet, and it came through. The odds are against this, though. > Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations. A million in what time period, and what are the usage patterns? Because from what I've seen, as long as the backend isn't in Python, Ruby, PHP or similar, a single hosted server easily vertically scaled to handle more than 2m million users, because it a) didn't need to handle 2m concurrent connections, and b) usage patterns were infrequent enough (users interacted only every few minutes at most).

by adrr 4y ago

klabb3 4y ago

I think you’re both right, even if I’d guesstimate the situation you encountered is very, very rare. You should make architectural choices that CAN be scaled within reason, on demand and ideally incrementally. That doesn’t mean you need to build your app on Kubernetes and automate welcome emails, surveys, metrics, A/B testing etc. But you probably shouldn’t build on top of fundamentally non-scalable systems either. This is provided you’re in an environment that can reasonably scale to 1M users or whatever, which isn’t true for all domains. Say B2B where that last B is only 10000 people world wide.

what-the-grump 4y ago
It’s difficult to explain to people what you said without the experience of living in the failures of early optimization. K8s from day one, a-b testing, programmatic quality control without any paying clients on the product, scrum master and a PM and a product owner for 5 devs! Whole thing feel like a Ponzi scheme to keep overseas staff employed, perpetrated by the overseas development shop. Unless you built something absolutely atrocious, scaling it vs getting it ‘right’ or ‘right enough’, is trivial. You couldn’t sign up to Facebook if you weren’t a college student. Chatgpt overloads daily so what? When your app becomes necessary to enough people, bring in your k8s evangelists and shove into x cloud provider. But by god it doesn’t take 30 people to write a marketable mvp.
- klabb3 4y ago
  Couldn’t agree more.
- deleted 4y ago
  [deleted]
- adrr 4y ago
  Maybe I had the fortunate luck that we never had issues of finding market fit. We also had lots of investment outside of software dev. Fintech for example requires significant investment in compliance(eg: kyc). Chatgpt doesn’t have competitors. Customers can’t go elsewhere. Twitter had the same protection when they launched, there wasn’t a short form social network so they could have full day outages. Friendster would be the opposite, when they closed signups, customers just went to MySpace. Scale goes beyond the ability to support traffic. It also means efficiently handle data/traffic. Heap is a good example, great product but they haven’t figured out to provide that level of analytics without significant costs which are passed on to the customer.
- vbezhenar 4y ago
  What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence.
  - doteka 4y ago
    Nah, statements like the above are a sign of lack of experience, missing business understanding and/or hubris.
  - lelanthran 4y ago
    > What's wrong with Kubernetes from day one? I'd use it from day one everywhere. Avoiding kubernetes is a sign of technical incompetence. Everywhere? Sounds like you're cargo culting. There's a use-case for it, and that use-case is when your load is so high you need the orchestration.
    - vbezhenar 4y ago

jdsully 4y ago

Post product market fit scalability is critical. But a lot of effort is spent on things that will never get traction in startup land. Before you get traction the times at bat is the more important metric.

SkyPuncher 4y ago

In you're case, you clearly already had Product-Market Fit. Most startups do not. It's far more valuable to build quick than it is to build for scale until you know PMF.

lelanthran 4y ago

> It really depends on the situation. No one at a successful startup says, we spent too much time on scalability in the beginning. They probably say the opposite. Depends. No one at a unicorn says that, but I've seen plenty of startups that. The unicorn is the outlier, not the rule. > I worked at one company that we couldn’t rack servers fast enough to keep up with our growth. Our competitor who was the market leader had to turn off the ability for new customers to signup to prevent their site from crashing under load. We ended up surpassing them. Were they still in business at the end of all this? Because it turned out you made a bet, and it came through. The odds are against this, though. > Getting a million customers isn’t that challenging and really a function of money. With $50 CPA, you just need $50m. 1m customers will take down most sites unless you do some optimizations. A million in what time period, and what are the usage patterns? Because from what I've seen, as long as the backend isn't in Python, Ruby, PHP or similar, a single hosted server easily vertically scaled to handle more than 2m million users, because it a) didn't need to handle 2m concurrent connections, and b) usage patterns were infrequent enough (users interacted only every few minutes at most).