Scalable system does not imply needing many machines. There is no reason you can't just deploy your entire system on a single host, but maintain the ability to reconfigure exactly when needed.
I agree with the general premise of avoiding premature optimizations, but designing systems that scale is important for several reasons:
- Startups grow exponentially, if you're playing catchup as you're growing you are focusing on keeping the lights on and hanging on for the ride. Important for a growing company to focus on vision.
- Software that scales in traffic is easier to scale in engineering effort. For example, harder for a 100 engineers to work on a single monolith vs 10 services.
- Service infrastructure cost is high on the list of cash burn. Scalable systems are efficient, allow startups to live longer.
- If the product you are selling directly correlates to computing power, important to make sure you are selling something that can be done profitably. For example, if you are selling video processing as a service, you absolutely need to validate that you can do this at scale in a profitable manner.
I also don't agree with the premise that speed of development and scalable systems are always in contention. After a certain point, scalable systems go hand and hand with your ability to execute quickly.
I like Heap's (https://heapanalytics.com) approach - capture everything, query later. Depending on your needs (Heap is front-end UI oriented), might not be the right fit.
I don't think it is as simple as learning that you can talk about it - you have to learn who to talk about it too. Not everyone wants to hear that things are not working quite as planned - most people would rather just hear "Great!"
Is there evidence to support that accelerators are pre-selecting based on elite backgrounds? It would be really interesting to see YC's % of founders from Ivy league + Stanford over time.
What he's saying is that the views you want to be SEO'd can be generated server side and bootstrapped into Backbone (hook backbone views into an element that is rendered server side).
I currently do this too - I'll add that it is helpful to use a templating language that will work both server side and client side so you only write your templates once.
What does become a pain is doing routers/controllers both client side and server side - end up writing some code more than once and in different languages. Harder to maintain, especially when changes are made.
Good points here, especially on session length when related to logging users out.
I do however disagree with: "Anyways, the point of this is that in almost all uses, mobile site versions are god-awful." While the option to view the full site should always exist, there are enough experiences that designers would want different on mobile. There is a subset of power users who just want the full experience - but I think OP is generalizing here.
Where do we draw the line as companies in terms of user data collection? Should we stop tracking our users entirely?
Government eavesdropping aside, I see the internet as just another form of communication. Anytime you talk to someone, you are entrusting them with whatever you are communicating to them. If you knew a friend doesn't keep secrets well, you probably wouldn't tell them any secrets. When Mozilla sends you that email with the tracking links, you are entrusting them with that data, and are hoping that the data leads to a better relationship between them and you or offers some mutual benefit.
What is different in internet communication is that it is hard for a user to determine what company is trustworthy and when that trust has been violated. Most users also simply don't care when that trust has been violated - no one should like that their user data at some level is sold to advertisers by Facebook, but that won't stop them from using it (I myself am guilty of this).
Should tech companies not collect user data in the fear that a 3rd party may one day steal that data? Or should they not collect user data for some other reason?
If you are in a crowded space, UX differentiation is a feature. In the case of close.io, they are competing against well entrenched market leaders. Making a high quality, easy to use sales communication tool is their MVP.
I'd be really interesting in seeing if the energy cost is lower than the average long term output. I'd be perfectly fine with leaving my iPhone plugged in all night if it meant it could generate me $x/night, where $x is greater than the electricity hit I get.
But yes - its about finding the right balance.