90% of all startups fail. This devastating figure is due to a variety of factors, which in their quantitative nature, can hardly reflect the pain and efforts behind the founding of a startup. According to Crunchbase, even basic product designs or service decisions lead in over 40% of all cases to the market not accepting the required solutions and the new company having to close its doors within 12 months. For the remaining contenders, a journey is just beginning, and its challenging nature is little comparable to anything else in the business sector.
When addressing the inevitable issues that arise as startups scale, it can be overwhelming to consider all the tools, technologies, and procedures that successful companies have adopted. Where to start? Do we need to do that? I wish we had a blueprint! While there is no one-size-fits-all solution, GS9 hopes to outline a rough guide that will help keep you on track and not overburden your team. It is important to note that this is just a rough guide and should be adapted to your needs.
Early Startup “MVP” Phase
At the very conception of your startup, the primary focus is validating the product and the business around it. For that reason, the technical overhead should be as low as possible. However, there are actions you can take now that will set you up for success in the future:
This section might seem redundant, but just in case: version control is the key to safeguarding and quality-controlling software development. This is the minimum we would recommend at this stage. You will want to track all changes to application code, application configuration, and system configuration in a version control system such as git. This will ensure you have a method of tracking all changes in your software and enable you to quickly revert any if required. There is very little reason to skip this step as it only becomes more critical over time.
At this stage, you are likely to be deploying manually, which is perfectly OK. Manually deploying to a platform you understand and are comfortable working with will allow you to keep working on developing your product instead of focusing on why a pipeline isn’t working as expected. Issues such as scalability are not a concern; choosing a platform to deploy on at this stage comes down to what knowledge exists in your team and what makes sense for your short-term requirements.
Other than these recommendations, further additions to your software process are likely to be a burden on your engineering team and have little value. Without validation of your concept and users requiring high availability of your system, advanced monitoring and automation will prove an expensive distraction from developing your ideas.
Once the idea is validated, and your product begins to form, your team will grow, and you will start to prove the profitability of your company by taking on additional users. These factors necessitate a development process that allows collaboration while also ensuring the correctness of your deliverables.
Whether you work in sprints or follow a Kanban approach, having a backlog will help coordinate your team members and provide a log of work that is done vs planned. As your development team grows, it will be essential to have a buffer of planned work available to them to know what they can work on and what the priority is.
The benefits of code review are a much-discussed topic on the internet, and we are firm believers in reviewing every code change. Employing this technique at this stage and integrating it into your process will ensure that knowledge gets shared around your team and help identify logical errors or missed requirements. This also establishes quality gates which helps enforce any style guidelines in place and provides a good platform for mentoring less experienced engineers.
Continuous Integration / Continuous Delivery
This is a great time to introduce CI/CD pipelines to your process. These pipelines should run your test suites automatically and provide feedback to developers about the state of their changes. Integration with your chosen version control system will allow automatic execution of your pipeline on merge requests as a flag to confirm that merging the change does not break the application. Continuous Delivery pipelines should automate the deployment of changes to your environment automatically, reducing the manual configuration and toil needed otherwise.
At this stage, you will be looking to increase the number of users of your system. You will need to ensure that the customers using your service are not interrupted due to errors, downtime, deployments, misconfigurations, or other issues. To handle this, implement a base level of monitoring and alerting which will tell you how well your applications are running and give you visibility into the live state of your environment. Most cloud providers offer some solutions for monitoring that you may be able to integrate with. Regarding what to monitor, a good starting point at this stage would be the so-called Golden Signals outlined by Google in their SRE book.
Infrastructure as Code
Defining your infrastructure as code at this semi-early stage will be much easier than adopting it in the future when you may have a significant number of resources to manage. This will also ensure that you have reproducible environments and allow automation of any further provisioning that needs to happen.
Having multiple environments means you have a testing ground for changes to your product. Tests like these can be too risky to happen in the production environment, so they should be done in isolation. If you have your production environment defined in code using an Infrastructure as Code tool such as Terraform, it will be extremely easy to deploy a copy of the environment again to create a dev environment, etc.
When you enter the growth phase, your team and the number of users will grow much larger. The ambitious growth of the company must be supported by maturing of your development process.
As the complexity of your application increases, you will identify essential metrics that require monitoring. Adding monitors for such metrics and creating informative and concise visualizations will enable your teams to troubleshoot complex issues and measure the impact of each change.
Similar to monitoring, as you continue to add users (and potentially complexity) to your system, it can get increasingly difficult to understand accurately how the system works or how users are interacting with the application. Implementing tracing will give you a clear view of what/why/how things happen in your system.
At this point, you have a comprehensive development, release, deployment, and operations lifecycle which follows best practices and enables your team. Where to go from here very much depends on the requirements of the team and the specifics of your systems.
The advice here is dependent on the bandwidth and experience of your team at each stage. It may be extremely difficult to implement these changes if they are entirely new concepts to all team members or if a new element in the process takes up a significant amount of team bandwidth. It is best to continuously evaluate your existing process and adopt these practices piece-by-piece, as needed. Do not change too much at once, and don’t adopt something that you don’t understand the value of. At Geek Space 9, we have helped many startups evolve their software process and implement many of the discussed changes, and we are always looking to help more people take this journey.