Published 12 Oct 2020

I'm open-sourcing my next side-project

TL;DR, here's the project: https://invoice.build

links to everything else that is now public are listed at the end of this post.

I am open-sourcing the code, roadmap, analytics, *everything.

For those of you who are comfortable in the open-source world this probably doesn't seem like a big deal, but for me it is. I'm a self-taught developer so I have lingering imposter syndrome and self-doubt about the code I write. I've been building projects online for at least 6 years and it has never really gone away.

I also tend to keep my projects quite private until I have something reasonably polished to share. So to put everything out in the open is just a little terrifying… But what's the worst that could happen?

  1. I could be totally ridiculed for code quality!
  2. The live project could be hacked as a result of accidentally exposing some environment secrets or framework/dependency vulnerability.
  3. Someone copies the whole app and makes it far more successful.
  4. No one cares and this is all pointless.

Ohh well, it is what it is.

If anyone copies completely then at least it's some kind of idea validation and the first two cases would result in better code in the long run. So I think, all things considered, the potential reward of simply not building in private again is worth the risks.

I'm also doing this in the spirit of ETHOnline, I think it is mostly for open source projects and protocols and whilst I didn't originally design invoice.build to be an open-source project, it's not an Ethereum protocol (yet), who knows where it might go.

Background

Not trying to toot my own horn here, just want to give some context to why I'm building this and why I'm doing that publicly.

I was originally a Mechanical Engineer in the Oil & Gas industry, at the same time I built a ton of online side-projects and ended up getting a job as a Full-Stack developer at Bitbond. Bitbond is heavily involved in Crypto, we mostly work with traditional banks providing tokenization tech. We also issued the first ever STO (Security Token Offering) in Germany back in 2019.

Last year I built another side-project called Remroll, a business payment processing tool for Ethereum tokens. Remroll has processed $100K+ worth of ERC20 tokens so far, mostly in bonus payouts, but usage has kind of fizzled out.

However, the process of building Remroll lead me to the idea of invoice.build. A couple of times I needed to invoice a crypto business and ideally it would have been in Dai or some other stablecoin. All I needed was a nice looking payment page that allowed the client to make the payment using a wallet of their choice.

I also happened to have a friend who was working for one of the big ERC20 projects that came out of the 2017 boom. He was invoicing that company in Ether (ETH) on a monthly basis and the process, as he described it, was a pain.

This is basically what lead me to build invoice.build. It's generally relevant to my job and industry, and specifically relevant to some experience I've gained from side-projects.

And finally, the idea of regular business payments / invoicing in Ethereum tokens is interesting to me, so I thought it would be fun to build.

The Idea

App Screenshot

A quick overview of what invoice.build is and what I'd like to see it become.

The idea is fairly simple, invoice.build is a pure utility app that helps you generate invoice payment pages for Ethereum based tokens.

At least that's what it is right now.

I'd like to provide an API or maybe even an Ethereum protocol that allows other apps to easily integrate similar functionality within their own apps and DApps.

Perhaps one day it might provide the option to utilize the more interesting payment protocols made possible by Ethereum, like Sablier, so invoice payments could be streamed over time.

This is what I love so much about Ethereum, the composability of value transfer, there are so many options and everything is open.

The Why

So why make it all public?

  1. I have a habit of building side-projects in unintentional stealth mode, and once I have an MVP, posting it to ProductHunt, Show HN and the like. I've had some minor successes, but generally this hasn't worked for me. I need to try something different and why not the complete opposite.
  2. The code is very rarely the moat.
  3. I don't have anything to lose by opening everything up.
  4. Being super transparent is valuable, it builds trust and trust in crypto at the moment is a serious issue.
  5. It gives me the opportunity to be totally transparent for ETHOnline.

The Stack

A quick overview of what I have built so far and the tools I'm using:

  • Frontend is a Nuxt.js (Vue) app that hooks up to MetaMask and WalletConnect for payments.
  • Backend is a pure Rails API connected to a PostgreSQL database. I also have an Express.js Node app that acts as a micro-service to the Rails API for doing some things with Ethereum data.
  • Hosting/deployment is done with some Dokku servers that I run on DigitalOcean.
  • Database is a PostgreSQL managed database provided by DigitalOcean. The database is simply used to store the invoice and transaction data, more about that in the Caveat below.
  • For local development I'm using VScode and Docker. You can spin the app up too if you want, just follow the Readme here.

*Caveat

The data (database) is not publicly accessible. i.e. where all the invoice data is stored. The transactions made to pay invoices are obviously publicly available on the Ethereum blockchain.

The long term idea is to move the whole thing onchain. Ideally everything including invoice creation will be put onchain, but I need to figure out the best way to do that. I've written smart contracts before, I've even written a combination of smart contracts for storing invoices onchain before, but I want to really think about it, smart contracts are scary.

There are also existing protocols in this space which I could use, Request.network being the most prominent.

So the database is more of a temporary solution for now. In the future it is very likely that invoice.build will only use Ethereum as it's 'database'.

I've been working on this project for a couple of months in my spare time, so it's missing a lot of features and the code is obviously not perfect.

I'm very open to feedback and collaborators (if anyone else thinks this is good idea). However, the point of open-sourcing everything is more about testing this idea that keeping the code private is very rarely the reason a project will succeed or fail and that building everything in public is valuable, even if the project itself fails.

Please find all the relevant links to the projects public pages below.

If you'd like to follow along as I build invoice.build I'll be posting updates when I can on Twitter.

$