One of the biggest motivation killers in releasing a side project is deciding when it is complete enough to be sent into the wild. Almost two years ago I wrote a post about a principle I use "Deploy First" to make sure deploying code to the server is the first thing I do as soon as I make a "Hello World" version of my side project. This is to prevent running into deployment and configuration issues, which can be demoralizing and exhausting just when I am excited to finally release my product to the world.

The second principle is what I am talking about today, payment integration. When creating a project you plan to make money from, after you Deploy first you do payments second. I have found that payment integration mentally signifies the end of a project to me, so it is normal to leave it till the very end. The problem with this is that it is very hard to know when the end of a project is. There is always that color, font or feature I can tweak, that leads to more tweaks and my side project is never finished. Declaring completion of a side project is one of the hardest calls I have to make in a software process that does not have deadlines. Once in a while I come to my senses and I am like "I am shipping this product today!" but then I realize, I have not integrated payments and suddenly, tweaking that font and feature suddenly become exponentially easier to do.

This was part of the downfall of Hatchpost. We never put a price on it. Years later it comes up in conversation and Ben and I say why don't we just release it and then, just as we look at the code we realize, there is no pricing page, no payment integration and a bunch of work to be done on the user to have recurring payment plans and then we push the task to the weekend and then it never happens...again.

Building in payment integration from the get-go is one of the ways I avoid the hurdle of never releasing projects that don't have a deadline and for projects, I am coding for fun and for profit.