I actually find it more interesting that quite a few of the obviously copied bits aren't even really worthy of copying if you're already going through the effort of building an entirely new product -- they're pieces of our product that could stand to be improved. :)
The live/test switch is a good example. It confuses everyone: you're just switching between the data that's shown, but everyone thinks you're switching the underlying state of your account. It's something we've had on our list to fix for a long time.
I'm a woman and a developer at Stripe. I don't see how welcoming women as well as men into the engineering -- and every other -- team at our company can reasonably be called "lying" or "dishonest." No, we can't singlehandedly change the gender ratios in the valley, but we can and will try to make our hiring process as good and fair as possible.
I don't think Stripes hiring process is anything but fair. Given that, the next developer they will hire is likely to be male and there are more likely to be a higher percentage of females in the non-dev roles than in the dev roles.
What I find dishonest is that they pretend this is not the case. They pretend that they are most likely to hire females.
They're sending a strong signal that female applicants are going to be treated fairly - not that the next hire is likely to be female.
To use a non-sex based example.
My partner is wheelchair bound some of the time. Despite the theoretical legal requirements access to many places is a complete PITA. Having to phone up every time to find out whether you can get in or not, or whether we can actually sit together if we can get in, gets frustrating. When you get to the Nth occasion of visiting somewhere to discover that you can't get in because of some step or narrow door that nobody has considered it gets very annoying.
Now - some venues have things like pictures of people in wheelchairs at the venue, or strong visible inclusivity statements, or some other strong signal that there is going to be zero problem with access.
Guess which places we're more likely to visit - even if there are many other locations that are theoretically accessible, but don't signal it as well.
What Stripe have nicely done is signal to every smart female developer that "we are open to hiring you". Judging by the interview experiences of my female friends this strikes me as a rather clever move. It's going to get them a stack of applications from talented women who might not otherwise apply.
I'm sure that will more than outweigh the loss of any folk who see this as political correctness gone mad ;-)
We certainly understand that for some specific billing situations, Stripe's subscriptions API may not be a good fit. That said, we've tried to accommodate as many use cases as possible, and I just wanted to make sure you knew we have a prorate => false flag that you can pass when switching subscriptions. We also have a concept of usage-based charges (invoice items). Your larger point of course still stands (that there are always going to be edge cases and custom billing logic).
I think the best approach for you would be to keep one or two simple subscription cases and suggest your other customers who ask for edge cases to implement their own subscription system.
I wish you gave me that "do it yourself" recommendation - that would save me a lot of time (trying to squeeze what I need into subscription model that Stripe has).
Now that I do subscriptions in-house only - I don't even need to know what Stripe web-hooks are, what are all these possible subscription models and what are their limitations. Just two simple calls: one to create stripe customer and another to charge it when I need.
Congratulations from another fairly new programmer. :)
One UI suggestion: I find it clunky when a site forces me to choose from price ranges that don't overlap (e.g. $5 to 10, $10 to $15, etc.). Generally people making purchasing decisions aren't thinking in terms of those kinds of ranges; they simply have a maximum budget in mind. I think it's better to allow users to specify "under $5", "under $10", etc. so that each successive group includes the previous groups. I realize there may be a case for trying to get customers to purchase the most expensive item they're willing to purchase, but more often than not having to click each range separately just annoys me and I leave the page.
Many of the included apps (like NYTimes, Amazon, etc.) have Chrome Web Store apps that are separate from their regular websites. (Of course, it's debatable whether these app versions are preferable to their standard website counterparts.) The Web Store team emphasized to us the discovery aspect of the store. They also seem to be pushing Chrome Web Store payments as a way to increase paid conversions through one-click purchases from users who need only enter their CC details once.
Thanks for the feedback. The date mixup was a typo that somehow escaped our notice despite several re-readings, but good point about reminding users what the service is. That you yourself think about your product daily is no reason to entertain the fond hope that users sign up and then immediately frame a screenshot of your site on their desk to gaze at lovingly, just waiting for the next moment they can throw you a pageview.
I actually find it more interesting that quite a few of the obviously copied bits aren't even really worthy of copying if you're already going through the effort of building an entirely new product -- they're pieces of our product that could stand to be improved. :)