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?
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.
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.
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.
So why make it all public?
A quick overview of what I have built so far and the tools I'm using:
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.
Originally published at garethfullers.site on October 12, 2020.
Hey I love the product, and idea. You have helped me map out how I am going to build in public, just wanted to say thanks for posting this it has helped me for sure.
Hi Gareth, thanks for sharing! I would love to have a chat and see if we can collaborate / I can help out. I am a non technical person looking to get more technical and get hands on experience in crypto applications (in my spare time). My day job is venture capital (3+ years). We are in the same timezone. Are you up for a call sometime?