The coding never really ends.
First of all, as a startup, you’re likely to cut out a lot of features you wanted to include in order to have a minimal viable product that you can bring to market as quickly as possible. If your product actually succeeds, you’ll want to add those features in later. Furthermore, customers or clients will be asking you for new features you didn’t originally conceive.
Second, bugs happen. Even with the best testing platforms, things always slip through to production. Users will also find ways to use and abuse your application in ways you’d never imagine. You should always find ways to improve your testing before release, but accept that bugs will inevitably show up in production and need to get fixed.
Third, the software systems that you built your applications are continuously changing. Whether its Windows, Linux, iOS, or Android, they are always releasing patches, security fixes, and upgrades. If you’re building a web-based application, the same holds true for browsers, be it Chrome, Firefox, Safari, Opera, or (shudder) Internet Explorer. Over time, you may find that your application is no longer compatible on the platforms its intended to operate.
Once you’ve accepted that you’re going to be continuously developing your application while you’re in business, its time to establish a release schedule. An effective release schedule identifies the tasks that need to be completed, prioritizes them based on both importance and urgency (two very different concepts), and allocates resources based on time available. This ensures that important tasks get done in time, without overburdening your developers.
I recommend using a three-tiered approach towards your release scheduling:
- Hotfix: A hotfix is an immediate software update that is both important and urgent. This is an all-hands-on-deck emergency that has to be applied RIGHT NOW, or your business will suffer disastrous consequences. You should limit the amount of resources allocated to hotfixes, and you should exercise strict executive control over its prioritization. Otherwise you will find your business operations in constant firefighting mode, constantly reacting to problems instead of growing your business.
- Service Patch: A service patch is less urgent than a hotfix, but still important enough that it should be addressed relatively quickly. (For example, a user-interface bug or a performance bottleneck.) As a form of continuous improvement, you should schedule service packs on a short but regular schedule, such as biweekly (once every other week) or semi-monthly.
- Scheduled Release: A scheduled release should be the meat and potatoes of your release schedule. This is where you are doing the important work of improving your product, adding new features, and stabilizing your architecture. You should be allocating more than half your development time and resources towards scheduled releases. Since they require a lot of continuous focus, you should space your scheduled releases once every two to four months. (Quarterly releases probably work well with the business calendar.) Avoid the temptation to schedule regular releases on a monthly basis, as this causes too much planning churn and forces you to pigeonhole harder solutions into a schedule too small to hold them.
Software development is continuous and grows as your business grows. And whats true in life is also true in business: if you’re not growing, you’re dying.