Inspiration
Amazon has a policy stating that if a product you buy from them has a lower price within a week of your purchase, you are entitled to a refund of the difference. Unfortunately, many aren't aware of this policy, and even if they are, it goes unused as it's a real hassle to do all the required legwork.
Kickback is something that people could and should actually use. A few days before LA Hacks, I bought a scooter. Just yesterday, the price dropped $10. Because the application hadn't yet been built, I had to go through the "traditional" process of verifying what I'd paid, checking the new price, finding the dates to see if I was eligible, and finally the tedious task of contacting Amazon. This experience made me realize how needed this product was.
Kickback has literally no downsides to the consumer, and offers huge potential upsides.
How it Works
Users log in through Google in our mobile application (or soon via a webapp), which also serves as a beautiful list of pending and successful refunds. We check your Gmail Inbox for new Amazon orders, and watch for fluctuations in price. If something drops (monitored via Amazon's Product Advertising API), not only do we recognize that you're owed a refund, but we also send an email on your behalf (from your account using the Gmail REST API) to Amazon, requesting that the difference be refunded to you.
Your only interaction with Kickback will be to sign up once, and then receive push notifications whenever we've saved you money.
Accomplishments
We're pretty happy to have made a simple way to passively take advantage of a great policy that you may not have known existed.
In terms of technical achievements, we were able to build a relatively scalable MVP in a short amount of time; we organized worker execution with simple in-memory schedulers that could probably handle hundreds or thousands of users as is.
We also made a really pretty app.
What's next for Kickback
This service could be very easily scaled; as more and more people automatically monitor products and get refunds, request overhead goes down due to overlap. The service could stay operational by charging a small percentage of each refund amount, or through donations. We built this on Azure, so it'd be dead simple to scale by switching to an actual Mongo cluster and a standard microservice architecture.
In the future, we'd also want to use some of Azure's built in caching/queueing features to make this a bit more asynchronous; requests are currently done inline because of time constraints. The fact that Azure did basic DNS for us was amazing, huge props for that feature.
Log in or sign up for Devpost to join the conversation.