Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I would argue that the product you see on the outside (Stripe) is a reflection of the work that gets put into internal only projects. In many ways, this sort of "build the things that people want to use" culture causes people to experiment, to hone their skills, and to develop.

Stripe landing pages almost always get tons of support on Hacker News. This isn't because they're just a good payment processor -- it's because their landing pages are unlike anything else in the industry. They could have slapped together a static site in Jekyll with custom styling and called it a day. Instead, they labored over a landing page that feels well designed with immaculate attention to detail.

Did they have to do any of this? Not really. But it shows on the outside -- and it works. Given that the world is filled with design that just copies Apple and Google, supporting creative R&D is a huge plus for them.

Internal tools are the best way to do that -- they let people experiment and learn without fear of consequences on the outside.



I see a parallel here with Square in its early days. They would do some finely polished internal projects like this, like beautiful information dashboards, and redesigned their website like every other month.

I don't want to be too cynical but it can function as a kind of elaborate PR and recruiting tool, as well as generally support the impression of the company being the Next Big Thing. As Square had to open up their finances and work on profitability, they got more focused on core product. I wonder if Stripe will follow.

I also wonder if there's something particular about payment processors.. maybe overcompensating? Is it part of the business model to kind of puff up a company around what should otherwise be a commodity-priced core service?


Good point. It really is a commodity service: treasury services and risk management.

And most of that should be fairly autonomous. The fat will eventually be trimmed. Just like at Etsy.


> I don't want to be too cynical but it can function as a kind of elaborate PR and recruiting tool, as well as generally support the impression of the company being the Next Big Thing.

Whether or not this is intentional, it's working that way. I've heard more guests on techy podcasts that work for stripe than google, maybe just because they're so enthusiastic about the culture that they always seem to bring it up.


> ..."build the things that people want to use" culture causes people to experiment, to hone their skills, and to develop

Maybe it depends on the size/stage of the company to some degree. In the startups I've been involved with (< 10 people), developers have little - if any - time to experiment with things that fall outside the core product.

Company hackathons (as mentioned in Stripe's case) can be a good outlet for that kind of creativity, but the kind of quality you mention ("immaculate attention to detail") doesn't come out of hackathons. The company's leadership still has to make those things a priority (which, by definition, deprioritizes other things).


Yes but at the same time, like they said in the blog post, this particular problem reared its head when they were approaching and passing 150 employees. At that point, yes, people can take some time off to work on a truly nice solution to a problem that, like others have said, mostly receives half-baked solutions.


It's interesting, we've talked to a LOT of companies about this as customer research for our SaaS product (https://carrot.io) and 150 is actually where this problem become unbearable. We see this problem first come up consistently at 30 people, become a major problem at ~100 people that starts to get lots of attention inside the company, and becoming a real hindrance and burning issue if not addressed at ~150+.

It's not at all surprising to us that both Stripe and Square have spent a lot of time and money on this problem to support their quick growth past 1,000 people.


You might be interested in https://en.wikipedia.org/wiki/Dunbar%27s_number if you aren't already aware of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: