Hautewheels

Cash is the best wedding gift, but I've always found red envelopes to be impersonal and often unremarkable (unless yours is the fattest).

Hautewheels is an online crypto gift card, designed for weddings.

Instead of giving cash to the couple, the gift-giver specifies some amount of money they wish to gift and pairs it with a physical Hot Wheels car. The couple gets the car, logs into Hautewheels.xyz using the physical purchase code on the box, and chooses to receive the money in Bitcoin, Ethereum, or dollars. As the value of their crypto rises, Hautewheels updates the couple once a year on their anniversary – and the couple keeps a memorable physical token of the gift-giver's friendship.

Crypto

Many of my friends, especially those in hospitality will never buy Ethereum because they're put off by its marketing. Crypto comes off as too neo-utopian (blockchain for farmers!) or too toxically masculine (chads, apes and the like). But while it's fun to sneer at cold-brew ordering crypto-custies, I think Bitcoin and Ethereum have potential for immense upside, especially as assets held over a multiyear time horizon. I bought my first ETH in 2019 and I wish I had bought much more.

I'm a big believer in making small bets with the potential for big reward. Because the risk is paid for by me, Hautewheels is a simple and whimsical way for friends to enjoy the volatility of crypto, without feeling like they're losing their principal (it would've been "free" anyways).

I don't know if ETH or BTC will go up in the future, but I am hoping I just bought my friends a bunch of cars.

Behind the Scenes

I hacked together this MVP over a two week period using tools like IPFS and ENS, as well as SMTP.js, Amazon API Gateway, and Netlify. I made architecture decisions to optimize speed and to get things out the door.

If you insist, you can see the Github repo here.

API

The most challenging part of this static site was creating an API to validate the PurchaseID on the back of the Hot Wheels box. I used API Gateway in conjunction with Lambda (abstracts away server management) and DynamoDB (Amazon's NoSQL database) to perform a look up on a table that is effectively this spreadsheet.

Because I'd worked with pixel requests at LiveRamp, I had already understood how APIs and client-server architecture worked, but understanding DynamoDB's API syntax was confusing and I found the documentation to be lacking. Endre Synne's tutorial was helpful for filling in the gaps; thank you Endre!  

Overall, with the exception of a few hidden nested UI elements however, I found AWS to be easy to use and I preferred the user experience over Google Firebase + Cloud Functions, which I used to build the first version of Audiograph years ago.

NoSQL

Both Firebase's Realtime DB and Amazon's DynamoDB are non-relational databases, however. Coming from the world of relational databases (postgresql and BigQuery), this felt unusual and ironically more complex due to NoSQL's lack of structure. Using Lambda functions, you can actually populate the database using POST requests, but in the future, I'd still like to set up a traditional postgresql database to house user information in an accounts table. A traditional db will also be helpful in converting Hautewheels from a static site into a web app, and dynamically loading content from cloud storage URLs.

Web3

Hautewheels is available on hautewheels.eth/ (IPFS/ENS) as well as hautewheels.xyz (Netlify/Gandi).

This was my first time using IPFS + ENS and I struggled to understand why an average user would want to utilize decentralized hosting over existing tools, mainly because decentralized web3 technologies seem slower and more expensive.

Registering hautewheels.eth/ cost $4 in transaction fees for an address worth $12 in total.

I also felt misled by ENS's branding. Contrary to its URL (https://ens.domains) ENS addresses do not behave like domains in the sense that you can't have URL paths like hautewheels.eth/accounts. Moreover, users need browser support or a Metamask extension in order for ENS to be useful. The "/" character is critical in order to trigger Metamask on desktop browsers, and because users don't often install extensions on their phones, .eth addresses are virtually useless on mobile.

IPFS and the concept of CIDs (addresses based on the hash of the content itself) felt more interesting from an academic point of view. I took pieces of Luke Gloege's tutorial to deploy onto IPFS using Github Actions, which was very streamlined and surprisingly easy. The only problem with IPFS is that it's super slow. Loading blog posts on vitalik.eth/ (hosted on IPFS) is still significantly slower against the same content loaded on vitalik.ca and it's the same for Hautewheels.

Finally, the payments function. For security reasons, I did not want to work with Smart Contracts in the v1 of Hautewheels. Instead, I used SMTP.js to trigger an email notification whenever a user tapped a button to transfer or liquidate crypto. Currently, I am handling the transactions manually (sending ETH via Metamask/Coinbase/Cash App), but I'd like to explore how to get the money into a user's wallet, probably with a friend better versed in Solidity or using the Lightning Network – I'll have to explore that further.

I think there is a use case for highly available, censorship resistant technology. From a macro POV, I can see how AWS's market dominance can threaten competition, but the user experience of an individual developer still benefits from the economies of scale provided by centralized providers. I'm unsure if there is a use case for IPFS, but I don't think it's an everyday use case like building websites for eCommerce.

Hautewheels will remain active both IPFS and Netlify. I'm curious to learn how these technologies will fulfill use cases in the future.

Afterthoughts

Building something from start to finish is a thrilling, fleeting, often exhausting feeling. It's the reason why I'm in startups.

I remember when Hautewheels was just an idea, and I also remember the months in between, when I thought that it would remain an idea, that I'd never build it, because it was not a priority, or that it was too hard, or too time-consuming.

Moments like these, when I can see the product in front of me, regardless of how small of a side project it is, I'm reminded to take things bird by bird.

Sometimes, when you're in the dessert for too long, a little pitstop might be exactly the to feel refreshed and excited to build again.

I think Hautewheels could be a legitimate multiplayer application. Beyond what was outlined, I don't have a roadmap for the project other than maybe talking to users, but I'd love to collaborate.

Please feel free to email me at hautewheels@proton.me or connect with me via my about page.

Thanks to Iris, Endre, and Luke.

Gallery