3 months ago I launched a weekend project into the wild called Go Freaking Do It. I meant to write about it sooner but you know how it goes. The project is heavily inspired by Go Fucking Do It created by Pieter Levels. The basic premise of two websites is the same. You define a goal and if you don't reach it, you lose money you bet on the goal.
The main difference between the two is that Go Fucking Do It works with credit cards and a traditional centralized database. And Go Freaking Do It is set up as a decentralized application using Ethereum network as its database and a payment gateway.
I used the project as a way to learn more about Ethereum, Solidity and dApps in general. Overall, I consider the endeavour a success. I learnt about limitations of Ethereum and got much more familiar with Solidity. The project also achieved great recognition by reaching Top 4 place on Hacker News home page and overall got 128 upvotes and ignited a heated discussion with 109 comments.
In the first two days of the launch it also got almost 13,000 visitors, most of it from Hacker News. Out of all these visitors only two people actually used the app though.
Since Go Freaking Do It is a weekend project, the code is not at its finest as one may expect. In fact, there were some important issues discovered in the original Ethereum smart contract and one guy even published an article about these issues titled Don’t “Go Freaking Do It“ - Smart Contract Analysis.
Unfortunately, since smart contracts are immutable, there was no easy way to fix these errors. And since the deployment of the contract already cost me close to $100, I was not willing to spend that amount again just on a personal project which I did not expect to make money. Thus, after fixing the errors I decided to kill the previous contract and launch a new one on Rinkeby network only.
Thus, the first lesson is to always thoroughly test the code before deploying it. Overall, I am pretty paranoid on launching a faulty contract into the wild and whenever I work on client projects I make sure to provide extensive test coverage. Evidently, this applies to personal projects too, don't forget that.
The second lesson learnt is that you shouldn't expect an influx of customers from exposure on Hacker News. People may visit your site out of interest but are unlikely to convert. I heard others experiencing the same.
The third lesson I learnt only after the launch and wasting another $100 on server costs running my own Ethereum node on the server. Apparently, one can just use Infura as a way to connect dApp to Ethereum network. Now the server costs me $5/month rather than $50/month. Of course, relying on 3rd party provider may not suit all applications but in this case it's ideal.
Areas of improvement
Since the dApp is just an MVP, there are several things that I would like to improve in it. The first being a React codebase. Currently, most of the application's logic is set up in one
Main.js file. It would be great to separate the logic into separate components for clearer and more maintainable code.
Third, since the project is only an MVP, it does the bare minimum. And as a result, there is no real backend that checks expiring goals automatically and sends email to the supervisor. It would be superb to get this functionality done and avoid checking expiring goals by hand.
I open-sourced all the code on GitHub so if anyone is willing to experiment with the project or make it better, go ahead 😉.