Building a Developer Cult • Hacker News Board

Re: Building a Developer Cult

#31

Post by bikeshaving » Tue, Jul 21, 2020, 5:43 AM UTC

zt wrote: post #5

Look, I know that the idea of being customer focused might seem trite, but I wanted to focus on one thing: it's the little things. "What actually differentiates stripe from the rest of the bunch though? It’s the little things.Stripe obsesses over creating a seamless CX. Small annoyances in applications compound. A user might not churn immediately because you have a bunch of unoptimized functionality or crappy UX, but…

I think you might be missing the point the article was trying to make when you took the negative emotion which the author was describing (“annoyances”) and turned it into a positive one (“delight”). I don’t think you can simply say delight is the absence of annoyance, and that good applications are ones which delight their users.

Because while delightful interactions can wow your users and get them to tweet about your application, the mark of a great user experience is that it goes largely unnoticed by the user. You don’t notice a door when you walk through it; you’d only notice it if you couldn’t get through it. We only pay attention to tools when things go wrong; as developers we are keenly aware of this fact whenever we have to debug code which stops working.

A seamless user experience should actually be imperceptible to the user, and I’m not sure this has anything to do with delightfulness or juiciness or any of the other stretch goals UI people come up with. The fact of the matter is, not annoying the user isn’t as sexy, and boils down to competence (writing bug-free code) and consent (not using dark patterns to get the user to do shit they don’t want to do).

Re: Building a Developer Cult

#32

Post by unnouinceput » Tue, Jul 21, 2020, 5:45 AM UTC

I liked this article. Is a prime example of how a shameless asskissing article should look like, this should be on top of every campaign manager as a must read for upcoming election battle.

Re: Building a Developer Cult

#33

Post by shaan7 » Tue, Jul 21, 2020, 5:46 AM UTC

unityByFreedom wrote: post #27

fny wrote: post #20

Earlier quoted context omitted.

I'll warn against getting way too focused on this as an early company. Getting something up and running is often waaaaaay more valuable then achieving Stripe level UX from the outset, and then as time progresses you must make a conscious effort to improve. Remember, Stripe has been an app for about a decade. That's a decade's worth of learning what users care about and what details matter. And clearly that's a decade…

> A trap I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about. That's odd. The point of focusing on users is to discover what users want. If you're not doing then you're not really focused on users.

But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.

Also, +1 to the parent comment. I worked at a startup where we made exactly that mistake - we delayed releases until it met a high standard of UX - took us more than couple of years. By this time, competitors that built a _much_ crappier product got userbase, and hence funding, and then used that to get their UX up to par (sometimes they wouldn't even have the features, they just faked it). We realized our mistake, adapted and stayed in business - but it was a difficult and painful process.

So basically - first get things up and running FAST, then worry about polish and laser-cut UX.

Re: Building a Developer Cult

#34

Post by IshKebab » Tue, Jul 21, 2020, 5:47 AM UTC

jacobsenscott wrote: post #29

arp242 wrote: post #22

I recently built a Stripe integration, and can't say I'm especially impressed. Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for trans…

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare. What do you mean by "there's no support for transactions"?

He means database transactions. I.e. the ability to do a series of operations atomically.

Re: Building a Developer Cult

#35

Post by arp242 » Tue, Jul 21, 2020, 5:47 AM UTC

jacobsenscott wrote: post #29

arp242 wrote: post #22

I recently built a Stripe integration, and can't say I'm especially impressed. Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for trans…

I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare. What do you mean by "there's no support for transactions"?

I haven't really worked with PayPal, so I can't really compare. I did some payments years ago with ... I forgot, so I can't really compare it to other competitors.

With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL.

Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be.

There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated.

The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".

Re: Building a Developer Cult

#36

Post by gregdoesit » Tue, Jul 21, 2020, 6:01 AM UTC

If we are taking about Stripe, we should mention the silent competitor barely anyone talks or knows about outside the payments industry: Adyen.

Stripe’s current, (private) valuation is $36B. Developers love them. Adyen’s current, public valuation is $43B (they IPO’d amongst little press coverage). Most developers don’t know about them.

So what is the difference? Market strategy. Adyen only goes after large businesses and has something many others, including Stripe cannot compete with efficiently: (far) lower pricing, higher market coverage.

The developer experience for Adyen is decent - no complaints, perhaps a bit less “magical”. They will definitely have a fraction of the customers, but those customers are huge. They get and seek little to no publicity compared to Stripe, yet have built a similarly sized business from the Amsterdam, the Netherlands, which is remarkable.

It’s a completely different market strategy, and company strategy. Read the Adyen values to see how different the two companies are[1] - Adyen putting “merchants” first, with a mention of support, while Stripe prioritizing developers and small businesses. And company culture could not be more different either - saying this as someone who knows both Adyen and Stripe employees. Both are companies to admire, and show that there is no “one” good way to build immense value.

It will be fascinating to see what happens as these two companies expand to compete with each other (meaning Adyen starting to go after small businesses, and Stripe after the largest merchants, with a differentiated pricing model).

[1] https://www.adyen.com/about

Re: Building a Developer Cult

#37

Post by rlonn » Tue, Jul 21, 2020, 6:03 AM UTC

ss3000 wrote: post #26

fny wrote: post #20

Earlier quoted context omitted.

I'll warn against getting way too focused on this as an early company. Getting something up and running is often waaaaaay more valuable then achieving Stripe level UX from the outset, and then as time progresses you must make a conscious effort to improve. Remember, Stripe has been an app for about a decade. That's a decade's worth of learning what users care about and what details matter. And clearly that's a decade…

That's fair and valid, but shifting your culture from one that's laser-focused on shipping features that work to one that cares about shipping polished features that delights users definitely gets exponentially harder as your company scales in size. The sweet-spot for making that transition is essentially as soon as you've found product-market fit, no later and no sooner, and missing that sweet spot even a little bit…

There is one way to make sure the product improves after shipping a quick-and-dirty first version: dog-fooding.

Be a user, for real. Many seem to think that just using the product equals dog-fooding, but real dog-fooding is when you can honestly say you get real value out of using the product. It is when you'd pay to use it.

When you use your own product and gets value out of doing so, you have true customer perspective and your needs are aligned with your customers needs.

Re: Building a Developer Cult

#38

Post by arp242 » Tue, Jul 21, 2020, 6:03 AM UTC

stu2b50 wrote: post #25

arp242 wrote: post #22

I recently built a Stripe integration, and can't say I'm especially impressed. Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for trans…

I think you're seeing what the benefit is, though: it feels like you're just using an API to some company's DB. Payment processing is one area is that just a complete nonstarter to homebrew on your own. It's fucking awful. There's no choice. Bank's still require you to transfer them files via ftp to make transactions. And god forbid the legal, and technical mess when you want to accept foreign currency, or even multi…

Yeah, I have no doubt that it's better than what the banks are offering.

"Homebrew on your own" is more or less what Stripe's API felt like though; the perspective I'm coming from is that I run a little one-person SaaS company with a simple and fairly standard subscription model, and I was surprised by the amount of "plumbing" you need to do for this.

Re: Building a Developer Cult

#39

Post by koreth1 » Tue, Jul 21, 2020, 6:07 AM UTC

stu2b50 wrote: post #25

arp242 wrote: post #22

I recently built a Stripe integration, and can't say I'm especially impressed. Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for trans…

I think you're seeing what the benefit is, though: it feels like you're just using an API to some company's DB. Payment processing is one area is that just a complete nonstarter to homebrew on your own. It's fucking awful. There's no choice. Bank's still require you to transfer them files via ftp to make transactions. And god forbid the legal, and technical mess when you want to accept foreign currency, or even multi…

Work in fintech, can confirm. Moving money around the global banking system is a pus-drenched no man's land of technological anguish and despair. Every time you think you've seen the worst of it, you find out you were wrong.

Re: Building a Developer Cult

#40

Post by raghava » Tue, Jul 21, 2020, 6:08 AM UTC

zt wrote: post #5

Look, I know that the idea of being customer focused might seem trite, but I wanted to focus on one thing: it's the little things. "What actually differentiates stripe from the rest of the bunch though? It’s the little things.Stripe obsesses over creating a seamless CX. Small annoyances in applications compound. A user might not churn immediately because you have a bunch of unoptimized functionality or crappy UX, but…

I have understood over years that, below listed things typically lead to "grand success" or "cults" [ tech or otherwise - but then, eveyrthing is "tech" now anyway!]

1. Enterprise readiness (in order of precedence: real business value [either brings money or saves good chunk of money], robustness, usability, integration capabilities, ease of on-onboarding, simpelr path to value-maximization. Good to haves: delightful user experience, great documentation)

2. Developer delight: The ecosystem (=> tools, platforms, training, autonomy, agency, motivation via empathetic management) offered to developers, in order to make them super effective, productive and efficient - to cater to the above listed. Note: "Developers" include Ops and Tech Support personnel too!

3. Customer delight: The above two leads to "customer delight" They see that the tool/solution clearly brings value, and that the support team is able to deliver the same as well - sustainably and happily.

This leads to a great win - for vendor and customer.

Building such an ecosystem is not a trivial or simple thing. Takes years, decades even.

In the end, that cutl gets formed - thanks to those ingredients that continuously keep "wow"ing the makers and the users. The "stuff" takes the limelight, but that's just proxy for the makers, their tools, skills and motivation.

This applies not just for software, but for many others! People value Toyota because Toyota's entire organization structure and inclination is on those lines - to 'drive' better value for consumers and their own people who offer'em.