From a POC to a Release Ready Software Product

At the early stage of your startup you build a POC / prototype (a Minimal Viable Product) in order to be able to present your idea as a product and show that it delivers value. Your POC / prototype is presented to potential customers, investors. You receive the desired feedback and you get to the conclusion that you need to transform the prototype into a production ready application as soon as possible.

Some of the challenges you will probably face (as there is a major difference between a POC and a release ready product):

• lack of documentations and product requirements

• lack of architecture for the existing codebase (the codebase is not reliable / reusable. It is difficult to maintain the codebase or to add new functionality. No documented architecture)

• POC quality codebase (low quality codebase built quick and dirty, functionalities hacked together, hardcoded data, strong dependencies between components with no reusability, no design patterns, no unit tests)

• no visibility about potential software security issues, risks and vulnerabilities

• lack of tools & procedures

• there is the desire to iterate fast and constantly add new functionality but also the product quality requires significant improvements

Steps to consider when you need to transform a prototype into a production ready app - before adding new functionality

• measure the quality of the existing codebase - use static code analysis to identify the most critical problems and vulnerabilities - code bugs, code smells, technical dept, code duplication. Improve the quality of the codebase by fixing the most critical items

• software security scan - especially if you are dealing with sensitive user data (don't forget about GDPR if applies). Run your code through a software security scan in order to identify and fix potential security issues and vulnerabilities

• Integrate crash reporting tools, analytics (log events related to application usage) and have the possibility to measure the app performance (KPI's related to memory, CPU, storage etc)

• Create a requirements hub and document at least high level what was implemented (you end up with high level product requirements for the existing functionality)

• Review the existing project architecture - identify gaps, opportunities for improvement (have clarity about what you need to do in order to end up with a reusable, reliable architecture that is easy to maintain & expand)

• Consider following agile methodologies in order to organise your work (potentially Scrum or Kanban based on what suits you more). Have clarity about the project timelines, rollout, deliverables

• Consider following a basic set of engineering procedures related to software project execution (coding standards, code reviews, branching strategies, unit testing etc)

• Introduce the necessary tools - issue tracking, version control, tools for creating automatic builds, static code analysers and others

• Create a basic test plan and testing strategy

• Introduce automated tests for the main application flows and functionality (gain confidence about the quality, reduce the manual QA effort and improve the effectiveness of validating intermediary and release builds)