Building a Developer Cult
subvert.substack.com
subvert.substack.com
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).
Source: Worked in software for payments processing a couple billions a year.
This is much more known now but not as known 6-10 years ago and guess who was very aggressive at maximizing this before I saw Stripe make a solid effort at this...
They've also got some of the highest quality transaction volume, who is doing a chargeback on Netflix? Nobody. Lot of possibilities down the road when you have access to this kind of volume.
Even for big B2B corps, it's the difference between a project you can lead on your own and get credit for it, or something that will go upper in the chain because of all the approvals you need for it.
In a previous life, to get an Adyen contract and dev. environment and then the prod credentials, it took us something like 3 months, and we had a smaller PSP integrated for a different project in the meantime. That meant that for any project we didn't have as much volume, we'd go though faster PSPs instead of reusing the Adyen connection.
Not only I discovered my company uses it, but plenty of other business I interact on a daily basis (from the market to utility-ish services) do.
I live there. There's a decent but not great startup culture. The services infrastructure is fantastic and there are many massive multinationals based here.
AMEX and Discover's transaction costs are a percent higher on Adyen, and I can't actually tell what Mastercard or Visa will charge since it is obfuscated. The cherry on top is the FAQ at the bottom that describes what interchange++ is but doesn't actually tell you a range of fees that it can be. I guess it's cool to see in detail all the middle men taking a cut of my revenue, but I'm way more concerned about the actual amount that is being taken out ahead of time instead of it being a surprise for every transaction.
[0] https://www.adyen.com/pricing?navItem=northamerica [1] https://stripe.com/pricing
The page I agree is confusing.
edit: Looking at their (listed) acquiring and processing fees, Stripe appears to be cheaper
That said, I don't know how Adyen's support is, but sadly Stripe's is honestly absolutely crap. Every single support interaction I've had with them has been incredibly slow and incredibly painful.
Adyen for example for Mastercard: €0,10 + Interchange++ (average total 0.90% - 1.10%)
Stripe advertised in Europe for Mastercard: €0,25 + 1.4% of transaction.
Large corporations are the larger, wealthier segment.
A big chunk of "startup business strategies" ignore this market. This makes a lot of sense for a startup. You don't really care what the bigger market is as a startup, you care what market is easier to access. Assuming the market is big (eg online payments), the size of the market isn't a limiting factor.
That works in-context. I'f you're trying to build a startup, landing a multi-year contract with a big company is a bad angle for multiple reasons. Not always, but mostly in the generic case. Long sales cycles. Checklist feature demands. Custom features. Besides being hard for most founders, it pushes in the wrong directions. Meanwhile, who cares if you're addressing a $3bn market or a $800bn market. Both of those are big enough for a startup aiming for $8m in revenue. Your problem is sucking and failure, not pyrrhic victories.
Also, if you are successful enough, small markets become big markets. When Google IPO-ed, they competed with yellow pages for mom-n-pop business & such.
OTOH, most of the market is large companies, governments, etc. That's reality, and it means something. Now that VCs fund startups so generously, a common pattern is bootstrapping in a shallow pond... then jumping into the main pond once you have momentum.
EG, Having a "developer cult" mentality, like stripe, at your base will serve you in the long term. Enterprise developers do have influence. It's never what makes a decision, but it can be a favourable wind.
And because you made a deal with them when you had no leverage, the terms will also be awful, and difficult to renegotiate. So you have to go try to increase margins off of smaller customers, all with a product that looks like what the person you aren't making money off of wanted it to look like.
Hypothetically speaking, of course. Because I definitely for sure did not work for a place who tried to go big too soon and ended up with a modest exit.
Actually looks like 43B EUR, so $50B.
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
[2] https://www.adyen.com/payment-methods#pmx=the-philippines
[3] https://www.adyen.com/payment-methods#pmx=convenience-stores...
[4] https://www.adyen.com/payment-methods#pmx=mobile-network-ope...
Adyen seems to implement every payment method you can think of. And if you don’t want to implement them, their white label payment page is able to dynamically show payment methods based on user location and merchant preferences.
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.
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.
Very unlikely, as both markets (smb payments and enterprise payments) is unlimited, there is a few chance they will try to compete with each other. On the other hand almost no company is able to be a leader in both the smb and enterprise space, because as you mentioned it, the cultures need to be different, the customer support need to be different, the product need to be different,... More info here : https://blog.luap.info/why-most-saas-companies-cant-be-succe...
What? There are only so many companies in need of (or open to changing) payment processing software at a given time. When it comes to larger firms, those numbers get smaller. That's the opposite of unlimited.
Concur, Microsoft Office, GSuite, Tableau, DocuSign, Salesforce, Adobe, Slack and Zoom to name a few.
We were processing a few millions a year at that time, which is quite small by enterprise standards. No idea how much volume it was years before when the company started using Adyen, I imagine not a lot.
Stripe dominates the hobby & startup segments with the hope that those companies will, someday, become very successful. Now, any company at a certain size will be able to switch between payment processors with little cost, but Stripe still has that initial relationship. They certainly have the opportunity to grow business with their current relationships over time, and in some ways more than Adyen can.
Additionally, Stripe will always work to get more payment methods & exist in more countries. It's always some work to do so, but number of payment methods isn't insurmountable, and it's only a matter of time before Stripe & Adyen are difficult to distinguish between their offerings.
Lastly, Stripe has a lot of breadth of products compared to Adyen. Stripe Sigma alone is a huge value add that a regular "insights platform" lacks. There's a lot here to unpack, for sure.
And their slogan "Our mission is to increase the GDP of the internet" https://stripe.com/about also alludes to the strategy of helping actually create more online businesses, as opposed to just getting all online businesses to use Stripe.
That hasn't been our experience at all. In our case (a few years back, they might've improved in the meantime) Adyen experience was pretty lousy. Not especially bad, but average - considering many payment gateway APIs were as bad.
In contrast, Stripe was (at the same time, and continues to this day) miles ahead, a pure developer delight. Properly documented, with working API wrappers, working examples, correct API responses. It just worked as expected and was easy to understand.
Unfortunately I don't recall specifics with Adyen as it was a while back, but I know we were pretty unhappy with it. To this day I've never looked at it again, while I recommend Stripe to anyone in position to use it.
"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.
I spent a lot of years in several companies thinking I could correct a bad vision or culture, and unless you're the CEO you can't. Poor execution of a good vision/culture is always correctable, although you should consider what is the root cause of that poor execution... often it's personnel.
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.
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 can make the transition very difficult and very costly. But the dilemma is, as most successful founders will likely tell you, we're only good at identifying product-market fit in hindsight, long after it happens (and it may never actually happen).
I've worked at plenty of companies that pay lip service to wanting to ship polished features that delight users while still overwhelmingly shipping features in a very utilitarian, timeline dominated fashion, long past the point where they've demonstrated product market fit.
As with anything in product/engineering/design, it's all about tradeoffs and striking the right balance, and where the right balance stands will always keep shifting under your feet as you make progress...
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.
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.
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.
If these two things are not equal then you're doing it wrong.
A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:
* I need a better lawnmower
* I need a better way to cut grass
The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.
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).
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.
And that's still not all, you ALSO need to do marketing and sales.
To take an example, there's about a bajillion 'todo' or 'notes' apps, I think because they are easy - simple data models, at the core. Because that is finished quickly, developers focus on the UI / UX, which is extra emphasized because they often live in the Mac / iOS atmospheres.
Some will do marketing on top of that, pretty landing pages, get featured in the app store and the low effort app news sites. But there's a lot (on HN for example) that miss out on that.
But that's just one highly competed area, there's not much you can do now to get a foot in the door - it's not a market "ripe for disruption" as the HN crowd likes to say.
Financial transactions on the other hand is really hard to get right at the core. Adyen is doing a pretty decent job there, I'm sure Stripe does as well, but they emphasize more on the UX and smaller customers. There's also others like Buckaroo, Icepay, MultiSafepay, and a couple others.
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.
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.
"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.
I used them for a side project. Once you find the right documentation it's straightforward to integrate, but finding it took 3 days and 2 support requests.
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).
What do you mean by "there's no support for transactions"?
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".
I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway.
So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first.
Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?"
With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back.
* If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic.
The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once.
Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.
So, even if Stripe is suboptimal, everybody is so much happier to be away from PayPal that they're ecstatic.
It's the equivalent of having a mediocre sandwich when you're starving.
While the docs are confusing and the API info incomplete, once past that the experience has been good. Having a pre-written embeddable JS widget that takes care of adding support for credit cards/PayPal/Apple Pay/Google Pay was a real time saver over Stripe.
The kicker is the default fees are higher than Stripe, but Braintree will negotiate.
- Checkout docs are definitely not good, there is a "Getting started" and then good luck
- the CTRL+F hijack is the most annoying thing I've stumbled upon recently. Please don't do that.
Payments are a huge, institutional mess under the hood, what they offer is light years better than what was there previously.
Honestly it's what 'you don't see' that's the good part.
Disclosure: I work at Stripe. Will pass this feedback along :)
Docs now save to your cache, so loading should feel pretty immediate.
What should we be more clear about in the Checkout docs? We're working on improving them, but it'd be useful to hear what you think. (Could you email me [edwin@stripe.com] and jackerman@stripe.com?)
We also made the Stripe Dashboard 20% faster since March. There's more work to be done here, though—and performace (specifically the customer page) is at the top of the list.
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.
The design, etc. is the gravy on top of a successful runaway train.
Before Stripe payment processing was abysmal. There was no thought at all given to the developer/implementer experience.
Stripe basically put a clean and straight forward API and product around the mess.
I know java is 'not cool' but it feels like javadocs in 2002 which are generally well organised by virtue of myriad of conventions, as opposed to docs in some other langs. which can be hit and miss, though getting better.
Stripe is a pretty good example of good product experience for those having to 'do the work', because they will likely have a lot of say in it, in the long run.
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.
> 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.
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.
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.
That's definitely my experience with Stripe support over the years, too. A definite degradation. Really annoying.
This describes the broader Silicon Valley tech scene quite well too.
People worship others for founding/funding X company, being employee #Y at a certain unicorn, creating a cool feature 5+ years ago for a dead app, etc.
I've found that their email support is far better than their live chat support (and I assume phone support too). The last time I used their live chat support I had a confusing back and forth until being told to just use email support.
Ultimately the "ease of use" thing is valuable to the developers (the stakeholders above couldn't care less), and Stripe seemed to identify that getting developer buy-in is super valuable for at least one segment of the population
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.
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.
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).
Having a decent publicly documented API was revolutionary.
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 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.
If the CPU load is high enough to impact scrolling, it will hinder people trying to get information from that page.
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.
https://stripe.com/, though I don't suppose anyone is going to have difficulty finding the stripe homepage.
Please don't call that a cult though.
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.
It's just yet another post on how Stripe are customer centric.
Less features but better quality including with UX.