YC Hacks Submissions
ychacks.challengepost.com
ychacks.challengepost.com
What I'm happy to see is that technically novel hacks won and not just hacks that are viable business ideas. (A javascript framework won a spot!)
Being a YC ran hackathon I wasn't sure what to expect. Far too many hackathons have turned into not being about doing something fun and technically impressive but rather mini-investment pitch sessions. There is a place for that but it's quickly becoming a bit silly. I love hackathons where you are judged by peers for the clever technical creations you create. I don't like hackathons where you are judged by sponsors, mostly for using their APIs (it's great to have sponsor prizes but that shouldn't be the reason for a hackathon in many cases).
One thing that got me was the amount of press around this hackathon. The outside world was watching it and you could feel it. It don't think anyone cared internally though that was hacking. It was just as relaxed as any other hackathon I've attended.
My wish list YC Hack next year:
- make it 48 hours (24 hours is almost too short and any longer than 48 is too much in my experience)
- less distractions (too many announcements. it was good at night though, but the music, while good, was too loud to speak to my teammates at points)
- do mini/fast pitches instead of floor demos. we were assigned a table outside and not many people came out there in the hot sun to see our hack. part of the fun of making something in the weekend is showing it off.
- keep it about this size. don't grow it. the lottery and pre-submission was the right idea. if you have to many projects, it gets hard to demo and goes on for hours (See TC Disrupt). The quality of apps was super high here because of the pre-application process.
Everything was amazing though. I would say it's in the top 10 hackathons I've attended of the 141.
Thanks most of all to Kat for organizing this thing. It was awesome.
The initial version uses the Google Prediction API as the machine learning backend, and obviously some tweaking would need to be done to the model to get it to 99% right, but I'm confident that for verticals like event tickets this service would be very useful. Imagine Coachella tickets not selling out within 5 minutes or a play at a local theater having an automatic discount the night before the show if half the seats are still unfilled.
{"item": 150242, "price": 1999.00, at: "2014-08-03T12:40:34Z"}
Then when rendering the product I call into your api to fetch the surge price adjusted value `/v1/150242` and get back: {"item" 150242, "quantity_left", 48, "surge_price": 2033.00, "original_price": 1999.00, "percent_change": 1.7 }We also have implemented a "real-time" aspect whereby the price can also fluctuate based on the number of users currently viewing/purchasing an item vs. the average number of users usually viewing the item (for example when Outside Lands begins selling their tickets at 10am PST). Other factors taken into consideration (as of now, but more to come) are: inventory_remaining, and profit_margin (i.e. how much you make on each sale).
They could monetize by allowing certain restaurants and events to purchase priority.
Would also like to implement finding facebook/eventbrite events in the future :)
I look forward to trying it out.