Sahil Lavingia- Founder. Early Pinterest designer, USC fan.
What inspired Gumroad?While still employed by Pinterest, I was working on a small piece of art one weekend. All I wanted to do was sell it online to my followers. I figured it would be pretty simple to find a service for this, but it wasn't. So I built a quick prototype of what was basically bit.ly for payments with Python on App Engine and threw it on HN. The response was amazing. I'm not one to rush into stuff, but when I thought about how fundamentally empowering this was, I knew I had to do it.
You're building for creatives and other nontechnical people. What kind of design challenges does that introduce?Most of our customers are highly nontechnical, and don't even think of themselves as businesses. So every aspect of the product is optimized for simplicity. Our goal is to make selling to your audience as easy as Instagramming a photo. And what makes the problem even more interesting is that it's not just one kind of media. We're in so many verticals. Our recommendation engine, our workflows, have to be equally good for music, videos, games - There is no 'One Perfect Recommendation Algorithm'.
You're a designer by trade and an artist at heart. Any final comments on your design philosophy at Gumroad?Hm, just this- words like 'beautiful', 'simple', 'elegant' - you can apply these to anything we build here. But at the end of the day, they're just means to an end. The creators need to get money in the bank. Otherwise, the product isn't working. That is the real core of our design philosophy.
Tuhin Srivastava- Fraud Prevention Data Scientist. Friendly Australian, tennis enthusiast.
What's your setup?We have a simple service-oriented architecture on EC2. Aside from the main Rails app, there's a really simple Python Flask service behind Gunicorn that I work on. We use SciPy and NumPy for the ML stuff, New Relic and the Ruby daemon God to maintain stability and our SLA. We use SQS for what basically amounts to asynchronous RPC, and HTTP for synchronous RPC.
I thought many interesting fraud and machine learning algorithms were bottlenecked on CPU. Why Python instead of a lower-level language like Java or Go?In theory, yes. In practice, we're not really a Big Data shop yet. More of like, a Medium Data shop. [we giggle] Python, SciPy, and NumPy give us simplicity and iteration speed, which are key. Every transaction has a 300ms decision window for fraud on the first tier. We fast-succeed, so if we can't get a response back in the window, we let the second tier catch it after the fact.
That's really cool! Sounds like you have a multi-tier system, with different goals for each tier? I don't know a lot about ML by the way - can you go into a bit more detail?Yep, and sure. ML algorithms generally trade off between accuracy and speed. For our analyses, we've found that logistic regression is on the fast-but-less-effective end of the spectrum. A random forest is on the other end. The first tier's optimized for speed, so the easy and simple stuff is there. After that, the request is dumped into an SQS queue where the second tier can act more accurately.
Makes sense. One of the last things I did at Amazon was a quick JS widget that stopped users from entering credit card numbers into the address field. It was surprisingly useful.Yep, we've found that detecting keyboard mashing is a surprisingly useful anti-fraud tactic. We model the keyboard in a two-dimensional space, and calculate the Euclidean distance between each key. If the keys aren't sufficiently distributed, we know that they're probably mashing. There's another pretty cool thing we do, which is deliberately build models on subsets of the features, and rank these submodels. So usually we can fast-fail even more quickly, because we don't need a big expensive model or all the features.
Amir Haghighat- Generalist engineer, ex-Yelp'er, energetic soccer fan.
What do you currently work with?A bit of everything! I really like fast iteration. We have one giant Rails app for most of the site - you worked at Twitter, so you know what that's like - and I spend a lot of time there. We use Flight for the front-end JS - it gives us decoupling and lets us test and ship quickly. For testing - Jasmine for unit, Capybara and Selenium for integration. We were on Jenkins but it got too slow and complicated too quickly. We're on CircleCI now, which is well worth the 50 bucks or whatever.
You're talking about a lot of tests, but you also really like fast iteration. Don't the tests impact your speed of iteration?Yes and no. We're managing money and credit cards, so we need rigor. While that impacts our short-term speed of iteration, we've seen it actually help our longer-term iteration speed. We're also introducing decoupling at just the right time - the fraud service Tuhin and the others work on is a good example of the right time to do it. An interesting side effect of all our choices so far is that Gumroad's code base has always been decent - no hair-on-fire moments like some other startups. I'm actually pretty proud of that.
Any other thoughts?Before I forget - one of the huge motivators for us is seeing people actually making a living on Gumroad. The story that has stuck with me was when a comic book author asked us to pay him a bit earlier - turned out he'd made $4,000 selling his comics online and needed it right away to get by. He literally depends on my code for rent and food. There are many stories like this. It's a good feeling.
Thanks Amir!Of course!
Posted by Vaibhav Mallya on April 10, 2014. Don't forget to subscribe to our list to stay up-to-date!
Gumroad is looking for engineers and designers. sponsored