We use it for a few things. We use it internally for a few dashboards because it’s actually really nice to have real-time dashboard data with Firebase. We also use it extensively for live order updating. For example, when a shopper is picking your items, you'll be able to go on your order screen. There will be live showing like found or not found or whatever. You'll have live position updating of your shopper on the map. You will have live information of the status of the order like “Nicole is now picking up your order,” and all these kind of things, so you don’t have to reload the page or pull or anything. Just live updates happen natively through Firebase API, which is nice.

So before, we were having … not a huge, but we were having a fraud problem where people were placing orders, and they were getting fulfilled even though they were very obviously using a stolen credit card. So we started using Sift, which basically, we send Sift a collection of signals from users, so like they added this item to the cart. They tried to add a credit card, but it failed. They added this address and then they submitted. So we send them the collection of signals, and they run machine learning on those signals and send us back a classification of the user, and we use that as one of our elements to decide if we should fulfill that order or not.

So that's all happening in real-time. Without human intervention, you can tell. If they have a very high Sift score, you can say, “This person is clearly fraudulent. They’re using credit cards from six different places and ordering only Patrón.”

We use Twilio extensively for voice call routing, for texting. We, in fact, use it for MMS messaging as of recently...We do number masking. So the personal shopper never has your actual number, you call the Twilio number and it routes you intelligently to the customer. And vice-versa.

We use PaperTrail, so basically all of our instances write into SysLog entries that are shifted to PaperTrail.

We use CircleCI for our tests, but not for our builds. The builds are all manually triggered right now.

We use Rollbar for exception tracking. It’s fantastic. I've used other things, but Rollbar is just really, really fast. Their speed at development is amazing. The features, you can tell it’s developers building it.

Yeah, so we use GitHub, and we basically use a variant of continuous deployment where when anyone merges in a feature that they’ve finished with, they ship it immediately, and we bundle it up as a build pack and send it to all of our EC2 servers... Any developer on the team can trigger a build and deploy at any time. So on a given day, we probably deploy 20 or 30 times to prod.

The very first version of the search was just a Postgres database query. It wasn’t terribly efficient, and then at some point, we moved over to ElasticSearch, and then since then, Andrew just did a lot of work with it, so ElasticSearch is amazing, but out of the box, it doesn’t come configured with all the nice things that are there, but you spend a lot of time figuring out how to put it all together to add stemming, auto suggestions, all kinds of different things, like even spelling adjustments and tomato/tomatoes, that would return different results, so Andrew did a ton of work to make it really, really nice and build a very simple Ruby gem called SearchKick.

We use the Carrier Wave gem to sync photos for all the grocery items to S3, then we use CloudFront to serve them up.

We use Elasticache. Both Redis and Memchached.

We liked a lot of things about Heroku. We loved the build packs, and we still in fact use Heroku build packs, but we were frustrated by lack of control about a lot of things. It’s nice to own the complete stack, or rather as far down as AWS goes. It gave us a lot of flexibility and functionality that we didn’t have before. We use a lot of Amazon technology.