release now, not later (with an EAR of course).

A major flaw in the mindset of a great many indie developers is the need to infinitely tweak, tinker or build upon an app or project before its release. Whether it be in making repeated interface alterations, never-ending debugging, or as a result of a desire to keep it ‘private’ to safeguard their work, many developers end up releasing the app far later than intended, or often not at all – which is never a productive result.

In the software industry the term ‘MVP’ or ‘minimum viable product’ is thrown around a lot, but essentially it describes the stage when all essential features of the product are there (no more than the essentials), and they can be deployed. My philosophy in development is simple: release when you reach the MVP. Not a full-scale release, but what I refer to as an ‘EAR’ or an ‘early adopter release’. Basically this constitutes an invite-only product release, or a ‘first come first served’ limited user number release.

An EAR provides an essential component of any good software product: feedback. If you will, it gives you an ear to listen to your user’s opinion (ok, that was a terrible pun). As a developer or designer, you find yourself spending hours a day staring at the application, you know every pixel and every line of code inside out. This makes it impossible to take a fresh look at the application, and consequently it’s likely that you will miss a UI discrepancy or forget a simple feature simply because you do know it inside out. I’ll give a real-world example: I recently released a MVP of an updated version of PaintRibbon, which included an updated zoom mechanism which used a new custom slider control. This feature looked and worked beautifully, but when adding this feature, I removed the old ‘dropdown’ zoom level box. To me, this seemed a logical step, out with the old and in with the new right? As it turns out, this proved a huge problem for a variety of users who wanted to set custom zoom levels: the dropdown box allowed users to zoom in with decimal point specificity (ie 25.5% zoom), however the new slider only allowed zooming in increments of 10. Fortunately, I’d released this as an EAR, allowing this and other bugs (which may have seemed inconsequential to me) to be fixed before the large-scale release.

Other factors delaying release such as a fear of your ‘idea being stolen’ just seem ridiculous to me. I mean, you can either sit on the idea forever, and never release it, or you can release it now, get thousands of users and deal with competitors if the threat arises: the ‘we’ll cross that bridge when we come to it’ expression fits well here. From another perspective, if you intend to create revenue from the project, delaying the release is like Mark Zuckerberg hypothetically investing in MySpace: you’re just throwing money away.

In the software business, it’s vital to understand just one simple concept: when releasing a product you have a hell of a lot to gain, and very little to lose.