Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
1–10 of 20 posts
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#2I don't think they know what Twilio is.
The article has close to zero content about the company, from reading Chute's own website it looks like it provides an API service for managing rich-media UGC content.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#3Can someone explain what Twilio for media content means? Twilio is essentially API-driven telephony infrastructure. It doesn't look like Chute allows you to use an API to drive real-world audio-visual infrastructure (that would be cool!), but is rather User-Generated Content with some do-it-yourself APIs and libraries.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#4I don't think they know what Twilio is. The article has close to zero content about the company, from reading Chute's own website it looks like it provides an API service for managing rich-media UGC content.
Ha, it's an interesting point actually. I'm pretty amazed at the wonderful job Twillio has done establishing itself as the "normal" definition of API and platform.
Obviously, they're not synonymous, but seems a convenient enough of a hook I guess.
Then again, it's main TC that opts for that analogy.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#5Congrats, Chute looks like something which can become synonyms with images. On the other hand its interesting how Twilio is always used as the placeholder for API.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#6Can someone explain what Twilio for media content means? Twilio is essentially API-driven telephony infrastructure. It doesn't look like Chute allows you to use an API to drive real-world audio-visual infrastructure (that would be cool!), but is rather User-Generated Content with some do-it-yourself APIs and libraries.
Hi, one of the Chute founders.
It's definitely not how we describe ourselves, but I think the analogy they're gunning for is simply around exposing an infrastructure for a specific media.
User-generated is definitely a broad use of Chute but certainly not the only one. It's also being used where you have your own media (photos, etc.) that you want to publish and have a bit more flexibility in both how they're used and the info you can gather from the usage.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#7I just used a site with Chute for the first time yesterday (http://www.refer.ly) and it blew my mind how easy it was to grab photos from the various cloud like places I upload them to (facebook, flickr, etc) and use them right there on Referly through Chute's widget. Instead of having to do the old "Right click, save, upload" method. It is ridiculously easy and awesome. Well done, Chute.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#8What are the benefits of Chute over a service like filepicker.io?
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#9I just used a site with Chute for the first time yesterday ( http://www.refer.ly ) and it blew my mind how easy it was to grab photos from the various cloud like places I upload them to (facebook, flickr, etc) and use them right there on Referly through Chute's widget. Instead of having to do the old "Right click, save, upload" method. It is ridiculously easy and awesome. Well done, Chute.
Always happy to hear that and would love to learn more about how we can make it better and simpler.
Re: Chute (YC W12) Nabs $2.7M To Become The Twilio For Media Content
#10What are the benefits of Chute over a service like filepicker.io?
This is a great question Kevin.
I think it comes down to a couple of things.
1. File Requirements 2. Workflow
If you're looking to simply capture any binary data, Chute is not the ideal option. While we will offer access to even more sources than we have today, we're not focusing on the capture of documents, presentations or other non-media docs.
If you definitely need media, then we think we're a great solution since our tools only work with those types of files. That means that not only do we spend a lot of time working through how they arrive and get processed, but also in how delivered back to your users.
This leads me to my point about workflow. We've seen and learned that every app wants to use media files in different ways. That creates a number of unique challenges as a platform: authentication, rights management, terms of use, custom metadata, custom profile data, 3rd party processing ,etc.
For many, and we'd venture most, media apps - simply putting the file online won't be enough. It will have to go through a number of steps and more often than not, there's a need to capture additional data as part of the intake. Put another way, a media file's life only begins when it gets "online".
We're focused on those use cases first and foremost and think we'll be the ideal fit for anyone who needs the same thing.