Hacker News Reader

Comment by krm01 | Hacker News Reader

There's a noteworthy pattern I've observed over the last 24 months.

I founded a design subscription service for startups [1]. Many founders are increasingly tapping into subscription based services, whether that’s for design, development, sales etc. to help them reach a certain level of scalability.

Historically we’d have a harder time getting clients, but for many startups having these plug & play teams makes the startup much more lean. You don’t have to provide a gazillion employee benefits or other cash draining things.

its nuts how so many startups just burn through their VC money buying things that do not directly impact their product and business.

A startup should do nothing except build something people love. To do so find more economic and effecient ways to get to product market fit asap. You can do all of the fun stuff later.

[1] http://fairpixels.pro

View on HN

> its nuts how so many startups just burn through their VC money buying things that do not directly impact their product and business.

An old mentor of mine taught me this, and my personal observations over the years have backed him up on it.

Having too much money is a greater danger to your venture than having too little money. If you have too much, you're just going to spend it on things that not only don't matter, but are likely to incur greater costs down the road.

I'm a believer that startups should be cash hungry (but not starved). It helps keep the focus.

One of my coworker used to work in hydrocarbons exploration. He swears that they multiplied their finding rate by twenty after dividing their budget by ten. It seems what you say stays true at any size.

> If you have too much, you're just going to spend it on things that not only don't matter

Co-founder and I recently went through a round of VC interviews with at least 5-6 VCs.

Question I posed to him is "If we got $2.5 million tomorrow, what would you do differently than what you're doing today?" My point to him is that there's really nothing that we could do with $2.5m that we couldn't do today at a smaller scale/longer timeline.

It would be nice for other reasons like having a higher profile, accelerate some of our roadmap, etc.

Both of us walked away from the experience a little jaded, TBH. He's close to a circle of folks in YC and was perplexed by some of the folks that made the last batch.

Wouldn't a good answer be "run more experiments in parallel to find product/market fit faster?"

I'm not saying it's easy (or possible) in all cases, but an extra $2.5 million before you have product-market fit doesn't sound like something that is impossible to utilize in an effective manner.

I mean, that's exactly my reply to him: we do the same things we would do but at smaller scale/longer timeline.

End goal is the same: grow the userbase, get that revenue flowing.

Similar story for cloud services, we've seen startups burn through 100K in AWS credits before they even launch a product.

The "Kubernetes is actually not overcomplicated" crowd, I presume?

I hate to say it but it isn't though. In 2023 you'll probably want

Automated rollouts and rollbacks, Storage orchestration, Secret and configuration management, Service discovery and load balancing, Self-healing, Horizontal scaling, Automatic bin packing (on vms)

k8's gives you this if you want BUT you don't even have to use those things.

It is fine to use the cloud for your initial landing zone project. But once you are n-weeks in, you really should have 1/2 or full rack at a colo with enough bandwidth and storage to backup your on two servers.

I'd start with DO or Hetzner, https://www.hetzner.com/cloud

And then move to own hardware in a colo.

https://www.supermicro.com/en/products/aplus

At the same time, I'd probably keep each project as I went. From day-0 you should have some form of cloud presence in all the providers, at least a root of trust landing zone you can work from to build out infra should you need to.

Frankly a many companies wouldn't need something like that for a while, if ever. If you're really doing compute intensive stuff sure, otherwise for your average webapp what would be the advantage of rolling your own infra?

A webapp isn't a company. If you have a company, you should have at least half a rack of hardware in a colo. Being 100% on the cloud is a grave mistake.

I guess Netflix isn't a company then, since they use AWS after all. You might think AWS isn't a good deal but it's hyperbolic to call companies that are on cloud services as not being real companies.

I don't think Netflix is a startup, could be wrong tho. I hear they want to start a streaming division and venture away from mailing DVDs.

> A webapp isn't a company. If you have a company, you should have at least half a rack of hardware in a colo.

is the quote I was replying to. The parent doesn't mention startups, they say the word company so of course I'd have taken it as all companies as a whole. There is no hard and fast rule that every company must have "half a rack of hardware in a colo" or otherwise they're not a "real company." This is basically the No True Scotsman fallacy in action.

I mean basically a company just has to make money, and today, dealing with a colo and all is probably just going to get in the way of that for the vast majority of companies in the early stages. Making the claim that relying on cloud is a big mistake is a pretty bold claim as well

Indeed, which is why I find their reasoning quite suspect.

This generalising misses the point for me.

If you're trying to scale, fast, into the global stage "half a rack of colo" isn't going to cut it. You're going to need presence everywhere and that can be impossible to deploy fast.

If you're targeting say a single market, say North America, with fewer larger clients you're likely to be able to manage it from two DCs and can realistically manage it yourself.

It's just "right solution for the right situation". Cloud is absolutely not always the right solution.

I'm trying to come up with a charitable read of this that isn't no true Scotsmaning the concept of a corporation but frankly am coming up short. I might be missing some part of your argument here - why do you believe that dedicating resources (cost and time/expertise) to having your own hardware is always the right decision for a company with a software/internet based product?

Yes at some level, every company should have at least one rack in a colo and I think that point is very soon after it starts, months.

I didn't say only, and I did say you should have footprint in every cloud for when you need to scale or deploy in a region.

If there was an "App Template" for a company, I think have your own hardware in a place you control is super important. Cloud providers literally don't give a shit about you. It is about agency.

Where your rack is is basically not relevant. For most startups, AWS is great, even if it's more cost of colo, it's the opportunity cost and dynamism it offers. Use AWS until the savings of not doing so will not affect your ability to grow, or costs are not dreadful. Moving away from AWS is a cost optimization, it depends on the kind of business you have.

But more broadly, the value is IP, essentially know-how and lock-in with customers, relationships etc..

Not really, once you are up and running even then the economics of cloud are usually better than self host. Instance time is 10x more costly on AWS than self host, but, it's still very cheap.

Things like 'egress data' can be a problem, but for the most part, even if AWS is more expensive than self hoste - the 'total cost of ownership' is much cheaper in the cloud - usually.

Where a company puts the bulk of its resources, that is up to them for whatever reasons they have. I am not arguing against that. What I am arguing for is that you every company needs to have >1u running in a colo, with hardware that is largely theirs. Every company I have ever worked would be in the >=1rack range.

I will only address TC comments with supporting numbers. Just math, no boogeymen.

I don't think this is the right approach. The entire point of startups is that they are just starting up. A startup a few weeks in can run on a Raspberry Pi, but in three years they could need half a rack, or a couple dozen racks. Buying expensive hardware is pretty pointless when you already know that it will most likely be inadequate in a few months.

Not to mention that you need quite a lot of money and engineering resources to get it all up and running. And it's never one half rack because you also need to have a secondary site for disaster recovery and backup...

Running your own hardware makes sense once your cloud bill starts hitting five figures and your hardware needs have become predictable. Until you reach that point, you can save yourself a lot of headaches by just using managed cloud resources.

> From day-0 you should have some form of cloud presence in all the providers, at least a root of trust landing zone you can work from to build out infra should you need to.

I am not saying to not use Cloud. Use Cloud. But have your own hardware.

> Similar story for cloud services, we've seen startups burn through 100K in AWS credits before they even launch a product.

I've seen and experienced this too many times already. And AWS knows how to play that game better than startups. By the time credits run out the startup is so locked in to AWS there is no way out and then the big invoices start coming in.

> A startup should do nothing except build something people love.

Even if you build something people love, that doesn't necessarily mean you can monetize it.

No, but if you burn through cash on, say, Jira and a ton of plugins and a guy to admin it, developing your own UI toolkit, going full Web Scale DevOps Kubernetes madness from day one or building a designer microconcrete-with-gold-inlay ballpit-slash-lunch bar, you can monetise something and still run out of cash.

Oh, totally true. But its also possible to build a startup where you get customers contacting you that they love your product daily and its almost impossible to monetize.

Reply on news.ycombinator.com