HotelSaver.io – Risk Free Price Monitoring For Existing Hotel Reservations

By Matt Daum | 2 Comments on HotelSaver.io – Risk Free Price Monitoring For Existing Hotel Reservations

Last week we officially did a very quiet launch of HotelSaver.io. The concept is fairly simple: You submit your existing hotel reservation, we constantly monitor for price drops, if we find one we notify you immediately and you save money. I had the idea for this site a few months ago when I had made reservations in New Orleans for a bachelor party, then noticed the next day the prices dropped and I managed to save over 40% of the reservation by getting it price matched and discounted. At this point I thought “wow, that was incredibly easy, took little time and saved a ton of money”. Shortly thereafter and shooting it around with everyone here, it was decide we’re going to launch a MVP product and see what the reception is.

With this concept it is really easy to quickly blow it up into a massive product with complex algorithms, payment types, etc. however trying to follow our own advice to our clients we launched with the minimal features to make it useful to the end user: simple reservation monitoring and payment processing to get us paid. We knew the first version of the product would be far from finished in terms of design and feature complete, but we wanted to see if others thought the idea had legs. Here are a few things we did to cut down on the time to launch even more:

  • The initial design is based on a free template we found which allowed us to spend near no time on design. It works on mobile devices and doesn’t look terrible. None of us are great designers, so we figured this was well worth it for the first release.
  • Not over thinking user management. Over time we plan to add accounts to the site so you can see your existing reservations from a dashboard, however for this first version we opted to go with a simple “email” to link together accounts. Users submit their existing hotel reservation with their email which we use later if you need to retrieve it. From there you can retrieve your “active” (reservations that have not yet past) reservations in an email we email to you.
  • Payment processing. This one was a no-brainer for us. We wanted to be PCI compliant and also have a good user experience. Stripe we had worked with in the past and knew it was incredibly easy to use. We went with the checkout feature so we never would have any of their credit card information and it never hit our servers, making us PCI compliant.

We also wanted to get feedback from a small group of users. We posted it on HackerNews and immediately started getting great feedback. We knew posting this on the day we were traveling for the Holidays wasn’t optimal as we couldn’t respond to feedback immediately, we wanted to get this launched. We managed to make it to the front page of HackerNews for a while and instantly had 2,500 unique visitors that day, up from zero the day before! The feedback was great the main points were:

  • Everyone loved the idea and thought if executed properly it’d be great!
  • People didn’t like that we wanted to charge $19.99 regardless of if we could find a lower cost reservation. It was too risky.
  • Some of the design could use some love.
  • Pricing would be more interesting/better if it was a percentage saved or a money back guarantee.

Today we revamped our pricing strategy after the feedback. We knew the upfront cost was most likely a turn away for many users but didn’t know what percentage would hate it. After reading the feedback on the post and numerous emails, we’ve switched to a 20% of the amount saved. This makes it 100% risk free to the user. We won’t make money unless you save money. If we save you $100 dollars, you get $80 of it. We’ll be next week working on promoting the revised pricing strategy to see what additional feedback we can get as well as addressing the other parts of the feedback.

We’ll be trying to keep everyone updated on our adventures of launching our own product in house. We’re excited to try some techniques we’ve seen over the years and testing them out ourselves as well as trying some new ideas. If you have any feedback let us know!

Friday Links: How the magic happens

By Ashish Datta | Leave a Comment on Friday Links: How the magic happens

Happy holidays to everyone! Hopefully the eggnog has been flowing freely and if you’re in the Northeast you’ve been enjoying the unusually warm weather. I’d been planning to post the usual link roundup but changed my mind. I ended up seeing The Imitation Game last night and it inspired me to do something different. The movie is definitely worth seeing and if you work in technology it illuminates a connection to a shared past that most of us don’t often think about. So continuing in this theme, here are four links that’ll help explain how the actual sausage gets made.

Church–Turing thesis

This is the big one. Developed independently by Church and Turing, and eventually formalized by Kleene this axiom serves as the foundation for computer science. It lays out a framework for computation and defines the limits of what problems can be computed.
Read More >

How does a computer chip work?

Skipping over a few decades of research (and vacuum tubes) puts us at modern microprocessors. Today microprocessors are found in basically every piece of consumer electronics including your TV, car, tablet, and obviously laptop. But how do these actually work? At a fundamental level, it’s not as complicated as you think.
Read More >

Why should I learn about compilers?

Now we’ve built a microprocessor but how do we do anything useful with it? You’ve probably heard people talk about “programming languages” and a compiler is the tool that makes them magical. Read on to learn how a compiler translates text written by humans into instructions a machine can understand.
Read More >

How Does the Internet Work?

Ok we’ve established what can be computed, how processors work, and how we program them. Now we just need to get online. Unfortunately, it’s a morass of acronyms but the pieces generally fit together logically.
Read Now >

Bitcoin: Creating transactions with OP_RETURN outputs

By Ashish Datta | Leave a Comment on Bitcoin: Creating transactions with OP_RETURN outputs

Last week on the train back to my parents’ place for Christmas I decided to follow @wmougayar’s example and read a couple of landmark Bitcoin and cryptocurrency papers. If you’re interested, William’s list is here and includes an interesting cross section of topics. Out of the list, Satoshi’s original paper Bitcoin: A Peer-to-Peer Electronic Cash System helped clarify the specifics of how Bitcoin works and why it has potential to be incredibly important. At nine pages including graphics and footnotes it’s both short and accessible so if you’re on the fence just go read it.

After reading the paper and following down the Bitcoin wiki rabbit hole I rediscovered the Script page on the Bitcoin wiki. Disregarding some cases, one of the key features of a blockchain is that new transactions must contain inputs from a previous transaction. With Bitcoin specifically, in order to use the output of a previous transaction you need to supply inputs that cause the previous output’s “Script” to evaluate to true. The Bitcoin wiki has a more eloquent explanation but at a high level this scripting functionality theoretically allows the Bitcoin blockchain to be used for things like:

  • Contracts including an external Oracle. To my knowledge this has not yet been implemented.
  • m-of-n / multisig transactions – requiring at least some number of private keys to be present. This has been implemented with varying degrees of wallet support.
  • Securely and permanently storing arbitrary data inside the blockhain. Implemented and what we’re interested in!

So stepping back a bit why would you want to store data inside the blockchain? As it turns out the blockchain has a few properties that make this an attractive proposition. First off, because of the public/private key cryptography scheme it’s only possible to “spend” the coins in an address if you know the address’ corresponding private key. Concretely, assuming that private keys remain secret I can’t create a transaction using an address that you control as an input and viceversa. So by creating a successful transaction you can vouch for the fact that you do in fact own a private key which may have in turn been used to sign an email to me, been used to buy a beer at a bar, and so on.

Next, once a Bitcoin transaction has a sufficient number of confirmations the data contained within it is effectively immutable. So for a nominal fee you can create something that is “set in stone”. In comparison, creating and running a similar system from scratch would be extremely expensive. And finally, the blockchain is distributed so thousands of machines have a copy of what’s happened. Barring exceptional circumstances, you’ll have access to the data even if a high percentage of nodes fail.

For all of this to “click” you’ll need an overall understanding of how Bitcoin transactions work under the bonnet. Ken Shriff has an excellent write up at Bitcoins the hard way: Using the raw Bitcoin protocol explaining what pieces go into creating a raw Bitcoin transaction. What makes an OP_RETURN output special is that the OP_RETURN keyword immediately marks the output as nonspendable while also accepting a second parameter of up to 40 bytes. That second parameter is where we’re going to stick our immutable data and since the output isn’t spendable creating this transaction won’t cost any coin.

As much as I love getting my hands dirty I decided to cheat a bit and use bitcoinjs-lib to build the transaction and then Chain to push it to the Bitcoin network. As it turns out, it’s possible to use bitcoinjs-lib in a browser via Browserify but you’ll need to hand modify the output to export “Buffer”. I have a “Dashboard” setup at http://code.setfive.com/btcscript/ with this all set up and it’s viewable on GitHub at https://github.com/Setfive/setfive.github.com/tree/master/btcscript. To use this, you’ll need a private key in WIF (Wallet Interchange Format) for an address with coins or you can generate keys and fund the address.

From there, you’ll need to take the following steps:

  • Make sure the private key field is populated
  • Under “Check Address” click “Refresh” to get the info about the public address
  • If there are any unspent transactions, click one to use it in the new transaction
  • If you want to actually send some Satoshi fill in a destination address and amount
  • Otherwise, you can enter up to 40 bytes of data in the OP_RETURN field
  • Click “Send” and you should see the transaction ID that was created
  • You can view the details for the transaction on https://blockchain.info/

I created a transaction using 1vaRGdVr9pqr9kEqJLoSMdN5MsjXBUrTN and if you can see the details at 1f5d645dde93a663427c60b3fb7d139f37343446e39a9d97bf56c4138083b109. If you scroll to the bottom under “Output Scripts” you’ll see the full output Scripts along with the data I included with the OP_RETURN keyword. Additionally, the guys at coinsecrets.org are tracking transactions with OP_RETURN outputs so your transaction should appear there.

Anyway, that’s how OP_RETURN works. We’re hacking away on Bitcoin Scripts in general and will follow up with a post soon.