Hacker News Reader

Comment by cperciva | Hacker News Reader

2¢, 3¢, 10¢ per day, does that really matter?

It doesn't matter right now, but if you're building a company which you hope to scale up, it's good to have costs which won't get too big when said scaling happens -- because when your company explodes overnight, you're going to be too busy keeping everything else running to spend time reworking your backup strategy.

(Also: If you don't have backups now because you're "not big enough to have data worth protecting", you're going to be too busy to start doing backups when you suddenly do have data worth protecting.)

View on HN

> but if you're building a company which you hope to scale up

This is a popular sentiment among engineers at startups and in my opinion founders should work hard to (kindly) beat it out of the team as soon as possible.

Basically, you can use that line to justify nearly any engineer hobby. We need microservices! We need message queues! We need master-to-master replicated NoSQL databases spread geographically! We need Redis, Kafka and Cassandra with a CQRS event source pumping data in there, oh and also to a Postgres so we can do arbitrary queries for management reports! We need our backups to cost not 3 but 2 cents a month!

But the truth is that, statistically, the chance that a startup will not actually scale up, is much bigger than the chance that once it does, the sharply increasing Tarsnap bill is going to drive it to bankruptcy.

I agree with you that you need backups from the start, but whether they cost $.02 per month or $10 per month initially really doesn't matter. There's a lot of features to build (and kill), users acquire, content to market, and the team is tiny.

I used to laugh about Twitter during their early growth days, fail whales all over the place. "What, they made that in Rails? Idiots". Now that I'm a startup founder myself, I realize that they did it perfectly right and I strongly doubt Twitter would've been what it is today if they had wasted time getting the perfectly scalable tweet processing timeline before putting the site out there.

I think it's a false dichotomy that great architecture and fast iteration are at odds. In fact, great architecture is what allows fast iteration to happen.

Yes, simplify your system by using as few moving parts as possible. But that also means don't use bloated frameworks that silently slow down your iteration pace with technical debt.

So many startups I've consulted with were stuck with having to redo core architecture right when they found market fit. It's a tough position to be in. The main rule to follow is that good design allows better design to happen later, it's worth investing in that

I fully agree and I don't believe anything in my comment contradicts yours.

> So many startups I've consulted with were stuck with having to redo core architecture right when they found market fit. It's a tough position to be in.

Good point, but watch out for survivor bias here: plenty startups failed before they reached product market fit, and some did so because they wasted time doing the wrong things. All things be told, I'd rather run a startup that needs to hire you to fix the core at the worst possible moment, than a startup that fails. But I agree fully nevertheless: good design begets good design and it really doesn't take much time.

> I agree with you that you need backups from the start, but whether they cost $.02 per month or $10 per month initially really doesn't matter.

For one service, no. But you can easily have one or two dozen such services, and then it really adds up, particularly with per-user or per-server charges.

Reply on news.ycombinator.com