Appreneur Tip: Suicide By Release Date

When you are an Appreneur, it’s easy to get ahead of yourself. You’re an idea person. A money person. A vision person. You’re looking ahead, anticipating your success, and planning for the next phase. If you are savvy about the industry, you’re thinking about marketing. Promotions. Events. Commercials. Anything and everything you can do to let the public know about your app. You know an app will die on the vine without good marketing, so you’re talking to marketing agencies and preparing a suitably epic rollout plan. You’re looking into popular websites or magazines that might feature your app.

You’re looking at the calendar and you’re thinking about the best time to launch. You see a great opportunity around the middle of year. Your marketing team is talking about synergy. You craft a kick-ass press release and put together a short, pithy video extolling the virtues of your upcoming app. Your promotional team made a great suggestion for a new feature that you were able to work into the press release. You can see all the pieces falling into place. You commit to the date you want, because it’s just too perfect. You just know that if you launch on that date, it will be smooth sailing. All of these are good things and that is exactly where your head should. There’s just one big issue: your app is not done yet. It’s still in development. Maybe it’s even still in the design phase. In your fervor for chasing the perfect release date and rollout plan, you have neglected the most important thing about the whole affair: Will the app be ready for the public? Chances are, you are not a developer. Maybe you’ve dabbled in HTML or maybe you’ve used a wordpress site before, but you likely aren’t a coder by trade. The process of actually making the app doesn’t dominate your thoughts because you’ve hired a development house for that. They are working diligently to bring your vision to life. They are the experts, and you are paying them, so if you say that it has to be done by a certain date then it’s up to them to find a way to get it done. The problem is that software development just doesn’t work that way. People who aren’t coders tend to have a very idealistic view of how software is made. They assume that since computers are involved, it is mostly an easy or automatic process. They equate to something tangible and clearly defined like the manufacturing of physical goods. This assumption could not be more misguided. The truth is that software is much more art than science. The software ecosystem is a haphazard miasma of competing technologies that are constantly updating. It takes enormous human effort to maintain expertise in any aspect of the field and stay ahead of the curve. Any given web page you visit will be a stack of multiple programming languages on top of each other, and each language could easily require a lifetime of study to master. Even in the slightly more controlled environment of mobile design, where developers are typically sticking inside either the Google or Apple sandboxes, there is still enormous overlap with various 3rd Party technologies. I think people tend to view software bugs as evidence that someone screwed up. The common thinking goes that if a programmer is an expert who is doing their job well, there won’t be any bugs. This assumption is also misguided. If you have worked in software, then you know that expertise is the ability to minimize bugs or fix them quickly because it is literally impossible to avoid them all together.

The main reason for this is that no developer works in a vacuum. Every piece of code that one developer writes is in a language that developer did not create, and it relies on hardware the developer has no control over. A perfect piece of code written to precise specifications can still fail when it attempts to interface with other systems or encounters a faulty internet connection. This messy reality comes with an implication that is very challenging for budgets and release dates: Every piece of software, no matter how well designed or how expertly programmed, will contain an unknown number of bugs and those bugs will take an unknown amount of time to resolve. An app can work perfectly in a controlled testing environment and then break the second it goes live without any one person being specifically at fault. In a world where an app is expected to work on a huge variety of mobile devices that each have their own specifications and customized user settings, there can be literally thousands of individual configurations that will affect the app’s performance in ways no one could have anticipated.

There are other types of potential roadblocks that are fully beyond the development team’s control. Maybe your app relies on Facebook for a key feature and Facebook changes their API not long before your release date in a way that negates that feature. Maybe your app relies on a 3rd Party database maintained by a company that goes out of business. Maybe your app becomes subject to some freshly implement government regulations about Data Usage that will require some retooling. These are just a few real-world examples that I have witnessed which interfere with a long-planned release date despite everyone on the team performing at their peak abilities. Because of these facts, even in a best case scenario, the end of any App’s development is punctuated by a question mark. That question mark can be anywhere from a few days to a few months depending on the nature of the issues that arise. An honest app developer will be up front about this before you sign on any dotted lines. What you should take away from all of this is that if you set your release date too soon in your app’s development timeline, you could be running a huge risk that the inherent unknowns of the software process will scuttle your well-laid plans. The rule of thumb is that the best time to start thinking about release dates is when your app is feature-complete and has been through at least one full round of QA testing. At that point, the question mark is being actively filled in and it should be clear to all parties involved when a safe release date would be. The goal of all of this is to put you in a situation where the only thing you are worrying about during the app’s development is if it’s the best product it can be. Once you are confident that your vision has been achieved, then you can schedule your meticulous release plan and set your marketing juggernaut into motion. No matter how attractive a specific release date might be, it is never a good idea to rush development or QA testing just to meet an arbitrary deadline. All that does is increase your risk that unknown factors will arise to interfere your plans. If your product is good when they first get it, your customers won’t remember your release date or if it was late. If your product comes out on time but is buggy, your customers will always remember that the app didn’t work as expected. In an industry with immense competition and a consumer base that demands instant gratification, making a bad first impression might as well be suicide.