Hacker News Reader

I would add most companies do not have the product/engineering/ux talent to approach this problem. Stripe is in the unique position that its talent can execute on several internal “projects” that each individually could justify an entire company to build. Most founders / leaders care deeply about their enriching their teams’ camaraderie and collaboration -- even if only from a cynical rational perspective of onboarding, productivity and retention efficiency (though I would argue from talking to many of them there is also a benevolent side to that). It is an hard problem to get right and Home nails several important details.

Disclosure: I am a founder of https://slab.com that is also addressing this as a scalable SaaS solution.

I'd suggest that if you are building a product like this, it really needs to work on-prem. Many companies will not host this kind of critical information outside their own network.

Seems like premature optimization. One can build a huge product based on the companies that don't mind, and adapt for on-prem later depending on feedback.

It's not only an optimization problem.

Building Saas-first or on-premise-first leads your product toward distinct attractors (features, behaviours, compliance, etc.).

You can often tell when a product has been changed to do on-prem as well as the reverse. Those traces of transition can be painful for the developers and the customers. Like the other person mentioned there's a lot you probably won't consider in terms of features or compliance if you're not building for both.

There's also ops and support. Building something meant for a dedicated team to keep running is way different from something a team will do ops for as one of many things. A complex architecture (even if contained in a single VM) requires a lot more support from more capable support people on the developer's side as well.

You have to think through a lot there. It's not something to take on without careful deliberation but if you're sure you'll eventually need to do both you should strongly consider it. If nothing else make it part of every design decision and pay attention to operational overhead by your own teams because those problems might end up being customer problems.

It’s not even possible to avoid on-prem. Stripe Home is clearly searching repositories.

Perhaps using something like replicated.com if you don't want to do it yourself?

I agree, but where would you draw the line between spending time/money on projects like this and needlessly reinventing the wheel?

I see a lot of startups creating internal software themselves (e.g., CRM's, email marketing systems, etc.) with a similar rationale based on "values and principles", where an off-the-shelf solution would be a much better use of resources.

Ironically, Stripe's core product is one of those off-the-shelf solutions that seems to be a good fit for a lot of startups, yet some still choose to do things the hard way.

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.

> ..."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.

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.

We're in the HR business and we don't offer a cool off the shelf app like this (we should! I took notes!)

I don't know if you would find a good off the shelf product that meshed with Stripe's vision. Some of the discrete pieces, document sharing and search, maybe.

In a company of “knowledge workers” building (or operating in) complexity the “wheel” is how you do collaboration and sensemaking.

“Reinventing” implies this has been done right for Stripe (or any such company) elsewhere.

better use of resources

Effectiveness in complex environments is not necessarily efficient.

> I see a lot of startups creating internal software themselves (e.g., CRM's, email marketing systems, etc.) with a similar rationale based on "values and principles", where an off-the-shelf solution would be a much better use of resources.

I've also seen companies drown themselves in custom ERP systems to the extent that it actually impacts their bottom line.

Point is - if these types of projects can produce an ROI and improve the bottom line, then by all means do them. But know what you're good at - and better, know what you're not good at.

I've also seen companies drown themselves in custom ERP systems to the extent that it actually impacts their bottom line.

Possibly OT, but heck, they do it with AWS bills that coincidentally often track pretty well what it would cost to colocate bare metal and employ sysadmins.

If the costs track but you don't have the management overhead then I'd consider that a win for the company.

It's a gamble. But, there are other examples of this: the company that created Slack was trying to make a successful game when they realized their internal comms tool was more interesting. Will Wright was making a helicopter sim when he fell in love with the game's city-building tool.

Which he later went back to, Sim Copter

Nah, he finished the chopper game that Sim City grew out of.

"Wright continued to develop the editor for [Raid On Bungeling Bay] as a personal toy because he enjoyed it so much. He researched urban planning and realised that others might enjoy constructing and building cities themselves. The result was a more advanced simulation that eventually became SimCity."

- the Wikipedia page on RoBB, which also notes that it selling about a mullion units in Japan was a large part of what gave Wright the financial freedom to build Sim City

https://en.wikipedia.org/wiki/Raid_on_Bungeling_Bay

They also created Flickr. Both Flickr and Slack were detours to market internal tools to outside customers on the way to making a game which never actually got made.

Why can't Stripe do the same thing? It's got this gigantic customer base of fledgling businesses; why not start building internal tools and then, once they're mature and battle-tested internally, offer them publicly to the growing businesses they already work with? It's an ingenious move.

Stripe is so profitable that anything else they make will look like a joke for the first few years. It is easier to pivot from an unsuccessful product.

Calling people "resources" and looking for the cheapest way out tells something about values and principles.

I know what you're trying to insinuate, but just to clarify, as the OP used it, resources seems like money, and cheapest means you are thrifty, you know, that things that a site like YC espouses in startups.

I have a slightly irrational fear that companies that spend a ton of energy outwardly talking about their culture are the ones with the most insufferable culture.

My hypothesis is that these companies are overly obsessed with defining a “mold” of the type of person that belongs at the company, and if you slightly deviate from that mold then you’re disproportionately punished for it.

I think the Occam's razor perspective here is that an engineering job at most of these companies is 90% the same, same-ish pay, same-ish equity, sort of mission-driven-but-not-really work, etc.

What breaks a company out of commoditization is often culture and so companies will go to great length to demonstrate their differentiator.

(as a former founder and hiring manager at a bigger company who has spent a lot of time doing this in both settings)

Eh.

Only certain companies though are able to execute and maintain this type of stuff, and even then it’s still questionable whether it’s worth it or not. I would love to see where Home is in 2 and 5 years.

I worked at a company that used its own homegrown timekeeping and HR tool. Over the years it became poorly maintained as people came and gone and the company (and its needs) grew. Eventually it was decided to jump ship to an "off-the-shelf" product and everyone loved it because it actually did what it was supposed to do.

I highly doubt employees are going to feel more loved because the company decided to build their own wiki and address book.

(I'm the author.)

If it's helpful context, Home has been around for two years and People (its precursor) was made in 2014. We now have a team helping shepherd it along -- you're right that an staple is curating so it doesn't become bloated. We intend to continue to share updates as we learn more, so hopefully others can learn from what works (and doesn't!) as well.

We use Bamboo HR and it does a lot of this but not all. Having a quality intranet is important and having it integrated is as well. We use multiple solutions to accomplish the same thing but obviously this looks great and functions great :)

Keep in mind some companies are savvier than others with respect to how they market themselves, and that the dirt hiding under a pretty rug can be just as dirty as the other kind. Keep in mind a company isn't going to go to pains to point out the areas in which it's not thinking through process and so forth: would they bother discussing the workflow of an employee whose day is not significantly improved by the Home site? No.

Is the thing nice? Sure it's nice. But I think it's a mistake to extrapolate too heavily from that to other areas of a company's operations. Every tech company I've ever been at has had "dirt floors" in some form or another- a really shitty area that was paid little or no attention so the adjacent cathedral could have another layer of gilding added.

Even "awesome" companies have areas you would not want a job working in. If you were in such a situation, would you want your lot to be improved, or would you want to watch cutesy videos of people who work at your company you will likely never meet? Imagine being in such a position, raising the issues you are struggling with every day to whoever will listen, and being ignored in favor of resources getting devoted to a cool UI for editing out-of-office days. That would probably be, you know, a bummer.