
Building a Developer Cult - jgecawich
https://subvert.substack.com/p/stripe-building-a-developer-cult
======
gregdoesit
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](https://www.adyen.com/about)

~~~
dmitriid
> Adyen only goes after large businesses and has something many others,
> including Stripe cannot compete with efficiently: (far) lower pricing,
> higher market coverage.

The reason is: larger businesses will require more payment options than Stripe
offers.

India? Adyen got you covered: [1] Philippines? Yup, everything [2], including
offline payments in stores [3]. Mobile payments in Africa? No worries [4] And
so on and so forth. On their payment site they don't even list all payment
methods, there are so many. You search for a country or a payment method, and
they show what's available.

Stripe has a very long way to go to realistically compete with Adyen.

[1] [https://www.adyen.com/payment-
methods#pmx=india](https://www.adyen.com/payment-methods#pmx=india)

[2] [https://www.adyen.com/payment-methods#pmx=the-
philippines](https://www.adyen.com/payment-methods#pmx=the-philippines)

[3] [https://www.adyen.com/payment-methods#pmx=convenience-
stores...](https://www.adyen.com/payment-methods#pmx=convenience-stores-
Philippines)

[4] [https://www.adyen.com/payment-methods#pmx=mobile-network-
ope...](https://www.adyen.com/payment-methods#pmx=mobile-network-operator)

~~~
fogetti
This is seriously lacking in terms of what's available on the market in Japan
now.

No support for point payments (like RakutenEdy payment), neither Linepay,
Rakupay, Merpay, Paypay and other QR payment providers, nor Suica or Pasmo
pay, and this is still just the tip of the iceberg what's available in Japan
and missing in Adyen (Nanaco, Waon, dPay, auPay, etc). Just saying, before you
drink too much of that kool-aid.

I would assume it's lacking similarly in other markets too.

~~~
dmitriid
Yeah, and how many payment providers provide all that _and_ all the rest that
Adyen provides?

I'm drinking Adyen kool-aid because I worked for a company that needed payment
methods in Japan, _and_ in India, _and_ in Korea, _and_ in Latin America,
_and_ in Europe.

Adyen provides all that. Yes, they will not have 100% of local providers, but
it's still 100% better than any competition.

~~~
fomine3
GMO PG is famous option for EC but more enterprisey. [https://www.gmo-
pg.com/en/service/mulpay/](https://www.gmo-pg.com/en/service/mulpay/)

------
zt
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 it’s a
recipe to create a grumpy user. And grumpy users aren’t loyal users."

This is an idea I've been turning over in my head a bunch recently: the
compounding effects of delighting your users. That cumulative innovation that
comes from building for your customers....I sometimes get asked "what's the
killer idea behind [company X]". But there isn't one big thing. There are
many, many small things built on having a relentlessly customer-back attitude.
You can't just copy the "idea", you have to copy the way of working and
thinking. That's a lot harder.

Let's take Brex as another example. It's the segmentation, UX, marketing,
rewards, underwriting, etc. It's each of those things broken up into a hundred
subcomponents and iterated on. It's an entire ethos and operating model.
That's cumulative innovation...not a single idea.

~~~
fny
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 to polish a product to near
perfection.

A trap I've fallen in myself, and 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. Often you'll only learn that by having a product that
works and customers need from the outset.

~~~
unityByFreedom
> 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.

~~~
shaan7
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.

~~~
unityByFreedom
> 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.

If these two things are not equal then you're doing it wrong.

~~~
SifJar
I think the point is you can easily get so focused on making the experience
"delightful" that you work on things that would delight _you_ , but that your
users actually don't care about so much. And you need to take a step back,
build something functional but not necessarily completely "delightful" & then
figure out what your initial users actually do care about and iterate from
there

------
arp242
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 transactions! IMO a good API design should
be more thoughtful than providing an interface to your database.

I don't think the documentation is especially well written, although it's not
bad either. What's worse is that the stripe API docs hijacks my CTRL+F key so
using my browser search is a massive PITA. This is such a fucking annoying
fucking thing that I'll break my "don't say fuck on discussion forums"-rule
for this. I fucking hate it. I tried disabling JS but that results in every
navigation doing a full page refresh which easily takes over 5 seconds.

Also, browsing the docs isn't super slow or anything, but it's also not quite
fast enough to feel "natural".

The checkout docs actually _are_ pretty meh. Much of it is written in
"tutorial" form and unclear on details.

As for the site design ... it often takes >5 seconds to load anything after
clicking and it easily uses more than 100M of memory per tab. I recently
wanted to load a bunch of customers so I opened them in about 10 different and
my entire laptop just ground to a halt. I've actually been procrastinating on
some Stripe stuff I need to do for the last week because I dislike using the
UI so much.

Is it all absolutely terrible? No; it's passable, I guess. But do I share any
of the enthusiasm in this article? Not even close.

~~~
stu2b50
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 multiple CC providers.

~~~
koreth1
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.

~~~
DrBazza
Agreed. I had to implement a transaction audit using SOAP in 2019.

~~~
dillonmckay
We actively maintain multiple SOAP servers so an OEM can connect as a client,
and send us data.

The OEM required us to stand-up the servers so they could send us the data.

We also still use FTP for some vendors (we host).

------
brunojppb
In my previous job, I implemented the backend integration with Stripe and also
the frontend for iOS (Native Swift App). It was a piece of cake to get the
whole implementation done across the stack. Six months later, our company
decided to switch to Adyen so we could target more local payment methods in
different countries. Back then, Stripe wasn't so flexible on that. With Adyen,
we could for example offer "carte bancaire" in France and "iDEAL" in the
Netherlands with zero changes on our accounting and backend infrastructure. I
have to be honest, from the developer perspective, Stripe is light years ahead
of Adyen regarding docs and simple to integrate (simple != easy). But once we
deployed Adyen, our sales skyrocketed after we enabled local payment methods
for specific countries across Europe.

If you are outside of the US, you should really consider Adyen instead of
Stripe from the business standpoint. I am still a super fan of Stripe btw.

~~~
lucaswb
I work for Adyen in our developer experience team. It might have been some
time since you integrated but we would love to hear about your experience
integrating to Adyen and how we can make it more simple. (You can reach me at
directly at lucas@adyen.com or reach out to our team at developer-
experience@adyen.com)

~~~
brunojppb
Hey Lucas, thanks for the kind response! It has been around 2 years since I
implemented and honestly it wasn't that Adyen was bad or anything, but the
mental model was different from Stripe. Back then, Adyen was already fully
async but Stripe wasn't so it required some learnings. And once it was
implemented, I was actually blown away with the flexibility. In my current
company, I am actually advocating for Adyen and we had a few calls with the
sales team already, so it will most probably happen for us next year.

------
meagher
What makes Stripe good now is what made it good way back when they first
launched: Handling payments sucks and they make it suck less.

The design, etc. is the gravy on top of a successful runaway train.

~~~
Silhouette
The remarkable thing about the culture around Stripe is that they still get
the credit for the things they did well in those early days, even though they
are far from the same service now that they've scaled up.

Objectively, today's Stripe is often a relatively expensive and unreliable way
to collect money from your customers. The API and developer documentation are
no longer as simple and effective as they once were, particularly if you need
things like PSD2. Something fundamentally changed about Stripe's support a few
years ago, and it seemed like almost overnight they went from routinely having
knowledgeable people replying with helpful suggestions to having people who
can't even be bothered to read your message before hitting whatever button
sends boilerplate reply #74 with platitudes #27 and #53 at the start and end.

Much of this is understandable. Obviously you're not going to get senior
people from an organisation the size of Stripe today personally responding to
messages the way they used to. Some of the complexity due to PSD2 itself has
been forced on them. Appealing to a wider range of merchants with more diverse
needs is inevitably going to make some parts of the system more complicated.

However, the hero worship they still seem to enjoy in various forums,
including this one, _is_ remarkably cult-like now. Recommending the Stripe you
remember from days gone by, particularly if you haven't recently used any of
the other services now competing for the online payments market, might even be
harmful to those starting small businesses today, who might be better served
by one or more of the alternatives and should at least be considering the full
range of options available to them.

~~~
porker
This is my experience too.

> who might be better served by one or more of the alternatives and should at
> least be considering the full range of options available to them.

Which alternatives should I consider, if I need PSD2? I've written about my
experience with Braintree above; there's SagePay but every client has been
pleased to move away from them.

~~~
Silhouette
PSD2 implies Europe, so my first question is whether to accept cards as the
primary means of payment at all. The various direct payment schemes are
typically cheaper, more reliable and, in some countries, much more widely
used. If you are handling recurring billing via a Direct Debit scheme then you
are probably also outside the scope of the SCA rules that are going to
interrupt payment flows using cards whenever the EU member states finally
insist on following them.

I've used GoCardless to do some of this, but depending on where you are based,
there seem to be quite a few other services now that offer some or all of the
relevant schemes.

~~~
porker
UK based here, so for most projects I/clients want cards as the primary
payment method due to the audience as they are one-off payments.

I've used GoCardless on one project; as the developer I didn't enjoy the
experience at all. Setting up testing for all states was painful (as was
getting items to the right state to use their scenario simulator). I see
Stripe have rolled out UK Direct Debit support now; hopefully their
documentation and testing story are better than GoCardless.

~~~
Silhouette
I certainly agree that testing these integrations is unnecessarily painful,
but given that both Stripe and GoCardless offer much the same facilities -- a
single sandbox environment, but without comprehensive simulation of all
important scenarios and with nothing useful for either automated integration
testing or offline simulation at the developer's desk -- I'm not sure I'd say
either is much better than the other. The only major difference I can think of
is that since they simulate roughly realistic timing as well, GoCardless can
also take several days to complete a test run for a new integration or bug
fix, which is obviously absurd.

------
zucker42
This article read like a puff piece that I got little more out of than "value
your users and build good software". It didn't seem like it offered much
substantial or specific advice.

~~~
d1str0
There has been a huge influx of articles from substack lately. I think they
are trying to grow their brand.

~~~
Sebguer
Substack is just a publishing platform, it's not editorial.

~~~
libraryatnight
Doesn't mean they're not submitting articles around to grow awareness of the
platform/their brand.

------
debaserab2
There was a long time when Stripe was taking a significantly higher
transaction fee than most other merchants for cc transactions yet there still
was fervent developer push to use it anyways (Note, this hasn't been true for
a few years and was only true during the first year or two of Stripe's life).

People made all kinds of rationalizations to themselves for using stripe at a
much higher cost simply because they didn't want to spend a couple more hours
using crappier API's or digging through crappier API documentation.

It made no sense to me at the time because while Stripe was nice, it was
usually only a matter of a couple hours/days to implement any of the other big
payment processors of the time. I guess that shows what the power of cultish
developer zeitgeist can do.

~~~
Silhouette
My first business that used Stripe was with them from their early days in the
UK, and my recollection is very different to yours. They were potentially a
bit more expensive in terms of fees than getting a separate merchant account
and payment gateway set up, but not hugely so and at least they were
consistent and transparent about those fees.

Moreover, they were _vastly_ different in terms of the ease of integration. To
take card payments via the traditional big banks and other established
services, you didn't just have to put up with awful APIs and worse
documentation, you also had to put up with onerous application processes that
could take days to collect the required information to apply, then weeks to
approve (or not), and even then often imposed severe restrictions for
businesses with no trading history up to and including piercing agreements for
company officers, large and long-lasting reserves being withheld, etc. The
_only_ other game in town for setting up online card payments reasonably
quickly and easily at that time was PayPal, which had a reputation somewhere
between Satan and the devil even then.

Of course none of this is unique today, and there are now many other services
available for taking payments via card or many other methods. But in those
days, it truly was a game-changer. As much as I criticise Stripe for its more
recent failures, I also give credit where it's due: many small businesses,
including at least one of my own, would not have gotten off the ground as
early as they did without Stripe.

~~~
debaserab2
U.K. was probably different, but in my mind both Authorize.net and PayPal were
the established players in the US market for online credit card transactions
before Stripe.

Authorize.net was (and still is) a "gateway" \- you pick the merchant and use
Authorize.net for the actual technical layer of processing a transaction -
which was kind of a confusing concept, but there were plenty of merchants on
authorize.net's marketplace that had much better rates than Stripe. I don't
recall there being an onerous application process or the restrictions you
mentioned, but it could be that I was shielded from that side of things.

Both Authorize.net and PayPal had pretty gross API's (and documentation) but
they were pretty solid once you got them working. Obviously it depends on the
nature of your business, but saving even 10 cents per transactions goes a long
ways for many and quickly justifies a day or even a week of additional coder
time. It wasn't that onerous of a task to implement one of the non-Stripe
options.

Paypal of course was it's own beast with it's insanely draconian policies
towards account holders, but I never had to deal with that (luckily).

------
chrismorgan
Ah, the new Stripe design.

[https://dribbble.com/shots/13676278-Home](https://dribbble.com/shots/13676278-Home)
covers it, and the comments on it are unanimously positive (and also shallow).

Yet I open [https://stripe.com](https://stripe.com) and observe a page mostly
incapable of hitting 60fps in its animations, which doesn’t scroll smoothly
because of this, and which is intensely CPU-demanding (it immediately makes my
laptop’s fans spin up, and I imagine it’d be draining the battery far quicker
than normal). And _that’s_ what I end up focusing on, rather than any
prettiness. I don’t like websites that make my browser slow and my computer
noisy, and will tend to close them far more quickly—either immediately, or go
in, get the information, get out, rather than perhaps lingering.

They’ve focused on subjective prettiness at substantial and unnecessary cost.
They could have implemented something just as subjectively pretty that didn’t
perform so terribly, but they didn’t. (Fortunately it’s only the front page
that suffers in this way.)

And on Dribbble: this sort of response is pretty standard: when something
popular and pretty comes up, people seldom make any critical comment on even
_glaring_ usability problems. When something is _obviously_ a catastrophically
bad idea, _maybe_ one or two people pipe up as dissenters, but even then their
feedback will be muted. And don’t get me started on how people _present_ their
web design screenshots, framing them on a background that is essential to
making key aspects of the design work, but which will be necessarily absent in
the actual deployment—this is rank dishonesty, in my opinion, but it’s also
ubiquitous on the platform.

As with Stripe’s popularity, these Dribbble things are a deliberate culture
thing (problem, I’d say): the Dribbble community is interested in prettiness
and doesn’t want to hear about impracticality or any form of negative
feedback. This has probably helped with the platform’s popularity—it lets you
feel good, everyone likes what you’ve made. Being largely invitation-only has
also helped them create and sustain this echo chamber. (“Echo chamber” is a
term too freely used, but it’s quite apt on Dribbble.) Otherwise I might
create an account named “Honest Critic” and make a habit of pointing out
problems in shots—not to be a downer or to condemn their work, but to help
them _improve_ it, and hopefully realise that they should care about these
things.

~~~
HatchedLake721
You really think anyone looking for a payment processing for their business
cares about CPU and frames per second on a marketing website?

~~~
marcosdumay
As far as they care about anything on the website. Do they care about it
looking pretty?

If the CPU load is high enough to impact scrolling, it will hinder people
trying to get information from that page.

------
concordDance
This is a PR release from Stripe isn't it?

[http://www.paulgraham.com/submarine.html](http://www.paulgraham.com/submarine.html)

------
smabie
> Anyone, anywhere can rebel against the system with Stripe.

If you consider working with a system that the government has perfect
transparency into and that is deeply integrated into every major financial
institution in the world rebellious, I just don't even know what to say.

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

------
preommr
I love stripe and they really do have some excellent designs, but that one
screenshot is pretty awful. The contrast between the text and the rainbow
image is so poor that it looks like a mistake rather than an intentional
design choice.

~~~
henriquez
Agree, I think they accidentally swapped the layers in Sketch or Photoshop or
something. Or maybe that’s some cult thing!

~~~
stu2b50
It's one of those weird swirly gradient things, not really my cup of tea, but
it looks _a lot_ better animated, on the page than the still.

[https://stripe.com/](https://stripe.com/), though I don't suppose anyone is
going to have difficulty finding the stripe homepage.

------
lsiebert
Building developer enthusiasm and passion? that's great. That's what Stripe is
doing, and I'm happy about that.

Please don't call that a cult though.

~~~
HumblyTossed
Indeed. It is very off-putting. Developer cults do more damage to the
developer community than not.

------
unityByFreedom
A "cult" is an entity with blind followers who would go over the edge like
lemmings.

Stripe is not that. They just built a good API, have made it more functional
and easier to use over time, and have great developer support (go on IRC any
time to chat with them). They accept criticism and fix problems. Cults don't
do that.

------
tannhaeuser
It's been some time I've worked with web payments (back in 2003 or so when
3DSecure/UCAF was new which would bring up your card issuer's site in an
iframe within your shop site, which still looked fishy), but I've always
thought a payment infrastructure/comprehensive standard should be mandated by
government, on similar legal grounds that a currency is issued in the first
place, and for protecting access to the market (the EU already puts strong and
maybe disproportionate reporting duties due to MiFid/MiFid2 for deposits, with
unclear benefits). Though I'm not very sure, as a payment provider has to do
costly things for fraud/money laundering/deposit protection.

------
BenGosub
Stripe is the most popular option out of not many options. So, when you ask a
developer what's their favorite payments API, chances are they are going to
say Stripe. Which isn't surprising at all.

It's just yet another post on how Stripe are customer centric.

------
TheOtherHobbes
This actually reads more like a content marketing PR piece for Stripe than a
summary of useful and actionable information for a startup.

------
_alex_
I stopped reading when the author described a feedback button as the epitome
of customer obsession. Is that really the bar?

------
hampfi
I believe, that there are plenty of areas where you could succeed by literally
just building what is already here but making it actually good.

Less features but better quality including with UX.

------
shay_ker
dang - can you change the title on this? It's less about "building a developer
cult" and more about "How Stripe builds for Developers".

------
tehjoker
Was hoping to read about developers participating in Stripe themed rituals
that resemble Eyes Wide Shut, a UFO cult, or an End-of-Days Revelation cult.
Instead, it's just something about executing business processes with customers
and good documentation. American business culture is something to behold.

