[adamboulanger]

I quite liked this article for associating Twilio's success with strategic decisions to treat developers as customers with particular implications for evangelism and growth. This approach isn't obvious because of the pressure to tie tool adoption to large-sized recurring enterprise contracts, often losing the individual developer as the engine of that model.

Also note, Twilio brilliantly dances between concerted efforts in grassroots developer campaigns such as hackathons while bringing down tier 1 enterprise contracts at the same time. This is awesome and not easily done. Developers are smart and ultra-wary of hackathons as thinly veiled API marketing attempts.

Over the past year, I've pitched a developer API startup to countless VCs, many of them top tier, and Twilio has almost always come up as a point of reference from the other side of the table. In many, many cases, the VCs will have passed on Twilio, not liking either the developer tool or enabling tech aspect of the company, and are now face-palming a bit...Only a bit...show me a VC that will wholeheartedly admit to making a mistake ;)

Overall, the venture sentiment towards developer tools is definitely shifting. A year from now I expect to see quite a lot more activity in financing this space, albeit, in domains that largely coincide with VC comfort zones. Twilio offers communications and telephony, which is a market a lot of folks are comfortable in, compared to education, health, government, or creative industries.

[guelo]

I came across a Twillio billboard the other day and the entire message was "Twillio. Ask your developer." I thought it was pretty bold marketing. No explanation of the service, they're just selling the fact that developers know it and like it.

[dragonwriter]

> they're just selling the fact that developers know it and like it.

The less-overt (and perhaps more important) message from that billboard is to developers that they should know it.

[tptacek]

Thinking about what it was like selling ideas (or, more accurately, failing to sell ideas) in meetings on a marketing team, all I can say is:

Whoever came up with that billboard is awesome at their job.

[seizethecheese]

Developer as customer model seems to be Stripe's MO too.

This seems to be driven by a few phenomena:

- For large companies, developer hours are becoming a large source of cost, so companies can charge a premium by lowering developer time demands.

- For independent developers, these services enable rapid prototyping and increases probability of finding product market fit.

[debaserab2]

It always surprised me how well Stripe does with developers. They are the most expensive option out there for a startup because their bulk pricing threshold is much higher than anyone elses (Paypal's first discount tier starts at $3k/m, Stripe's is $80k)

It always surprised me that developers don't identify this from the start. Sure, Stripe's APIs are a little easier to work with, but the extra time you'd end up spending implementing a cheaper competitor pays for itself pretty quickly when transactions start rolling in.

[petercooper]

As someone who's done mid 6 figures through a self coded PayPal Website Payments Pro integration but who's switching to Stripe once I've recoded things, Stripe's pricing works out about the same here in the UK even after the discount tier because their currency conversion fee is 2% instead of 2.5%. Stripe also accepts Amex whereas for some reason PayPal seems not to (in the UK anyway) which has caused numerous issues with US customers.

[Kliment]

Stripe are non-evil to me and non-evil to my customers. They have never done anything unexpected or screwed over anyone I know. Paypal have fucked over a lot of people I know for inexplicable reasons. They've fucked me over personally as well as a customer (They won't let me use my personal credit cards to pay anything via paypal, with or without a login, and they won't tell me why). A small difference in cost is absolutely irrelevant when the worst case situation on one side is "pay a bit more for good service" and the worst case situation on the other is "lose access to a nontrivial amount of money for many months and lose business for the same period".

[rtpg]

There are things that are basically impossible to do with PayPal until fairly recently that were extremely easy to do with Stripe. There's also the massssssive headaches from dealing with PayPal's API (message errors with no documentation) and PayPal's checkout flow can be a barrier.

[debaserab2]

Hmmm. I worked with the Paypal API a long time before Stripe even existed. What was impossible with Paypal's API that was possible with Stripes?

[StavrosK]

I haven't worked with the PayPal API extensively, but Stripe does a lot of customer management, subscription management, itemized invoicing, etc built-in, which I don't think PayPal supports.

Personally, I think any difference in price pays for itself in developer time, unless you have billions of dollars in yearly revenue. The PayPal API always makes me want to gouge my eyes out, whereas the Stripe API is so pleasing to use that I'm looking for reasons to integrate Stripe into things.

[debaserab2]

PayPal supports all of those: https://developer.paypal.com/docs/api/

You don't need billions in revenue to recoup the cost of a few extra developer hours. Pay pals new REST API doesn't even look that hard to use, either (I've only used their older APIs)

[joncalhoun]

First, Paypal doesn't just have a one time implementation cost. For example, refunds being limited to 60 days on Paypal will cause issues over time.

Even if the cost was fixed and upfront, a Paypal integration isn't an intelligent thing to prioritize for most startups. There are likely hundreds of other things a startup could do to increase its revenue by more than they would save in CC processing fees, so they should focus on those things first.

Eventually a Paypal integration will make sense, but likely not for a processing discount. Instead it will become useful for international payments, and even then most startups have enough headaches with Paypal that they choose to keep Stripe as the default checkout option, and use Paypal as a secondary option.

[debaserab2]

If you have to implement a payment gateway, how is it not a smart thing to carefully consider your vendor? That definitely seems like a priority to me.

I don't think there is any business decision involving costs that I want to make assumptions about or blindly select a "default option". Especially not one that represents a percentage of raw revenue.

The difference between a paypal implementation and stripe is not as significant as people make it out to be. I understand the intense paypal hate and it's well deserved, but from a pure cost perspective it often makes more sense than stripe.

[mgkimsal]

I did a prototype a couple weeks back and a dev friend of mine grimaced "why paypal? why not stripe?" A) I had a paypal account set up - it was literally 2 minutes of work to add the form, and B) I've had some setup issues with stripe - there seemed to be comparatively more setup work to get their modal form to work as demonstrated.

What was a bit disconcerting was that that was the focus - "why not stripe?" The rest of the service didn't even get much of a look, yet... every non-dev I showed the service too didn't bat an eye about paypal.

[aioprisan]

Your experience runs completely opposite mine integrating ecommerce solutions for large companies. The amount of complexity and headaches it takes to develop with PayPal vs Stripe is orders of magnitude higher. For instance, recurring plans with discount tiers is trivial to manage with Stripe, but a 10x complexity and cost basis higher with PayPal. Those engineers and technical debt is a lot higher than the cost savings, where you'll probably get a better deal from Cybersource or Authorize.net by a large margin (1.6% fees on my last project).

[mgkimsal]

"Your experience runs completely opposite mine integrating ecommerce solutions for large companies. "

My prototype was just that - a prototype - it took all of about 3 hours to put together, and throwing a paypal form on it was, as I said, about 2 minutes. I said nothing about "integrating ecommerce solutions for large companies".

[debaserab2]

How is it 10x more complex, exactly?

I have developed an application that uses Paypal's subscription plan API's. I just looked up the invoice that I sent to that client I did work for: 20 hours of work, including custom integration into their word press platform.

Are you suggesting that if Stripe were available at the time, this work would have been reduced to 2 hours?

[StavrosK]

I'm not you, and I don't know what you did, but the Stripe integrations I've done (which were very complex and touched on lots of functionality) took (much?) less than two hours, so probably yes.

[mattmanser]

You must live in an alternate universe. Trying to sort PayPal's shitty callbacks and test with their sandbox certainly was a good days work as recently as 3 years ago.

Also PayPal constantly tried to make your customer their customer and makes the whole process overly complicated with the login.

[corin_]

> You must live in an alternate universe

> as recently as 3 years ago

Maybe he lives in a universe called the present rather than the past? And even if you had a point, there's no need to be rude about it.

[icelancer]

> Stripe's APIs are a little easier to work with

This is the world's biggest understatement.

[debaserab2]

Not really. What is the Paypal rest API missing that Stripe has?

https://developer.paypal.com/docs/api/

I don't even use Paypal as a payment gateway for any site I operate currently. I'm using Authorize.net at the moment. It took about a day to implement. It wasn't as easy to use as I'd hoped, but it wasn't that bad. Certainly not worth a higher transaction fee.

[ignoramous]

It'd be interesting to see how much influence working at Amazon has had on the founders, if at all, in shaping the business practices, the customer-centric nature of the services offered, the overall culture of the company they built, the values it stands for, and the approach it takes towards software industry in general.

Most start-up companies in SV and the bay area are either co-founded by ex-Yahoo or Xooglers (of late, the Facebook/Twitter alumni has joined in as well). Is working at/working of Twilio different than working at/working of the start-ups that are founded by founders from other companies?

[RobSpectre]

Thanks Adam - we're rooting for you as you head out. Building a business serving developers is indeed as difficult as you say, but also - to be fair - an endless amount of fun.

Certainly nothing we'd rather be doing.