How our development process has evolved

In this post, we'll look at how our development process at Hailer has evolved and matured. Here are the steps that we took.

At first, development was ultra fast. The throughput rate was measured in hours, and the product changed visually and functionally as much as several times per day. Everyone working with the prototype had to accept a ton of bugs and constant interruptions. This stage worked with as little as one full stack developer and one customer success manager in our case and helped us to try new things and fail fast. In our case, we did rapid prototyping with real end-users involved, this required us to stay in a constant high alert mode almost 24/7. Fun, but not recommended for long periods.

When we gradually moved from rapid prototyping to rapid development, more planning started to go into how tasks were done. Our process gained some phases, while things still worked relatively similar. As the product began to have more complexity, the throughput time got longer, so we stopped releasing new updates daily. More developers joined the team. In our opinion, this stage works best with a small team where responsibilities are divided between front end/UI/UX and back end/DevOps developers.

Going from rapid development to actual product development usually requires a problem or crisis. This can be a critical problem that leads to downtime in the service or a significant slowdown in release cycles. This is because SaaS products that have been developed with speed collect a lot of technical debt, which means that a lot of code refactoring has to be made before any new or improved features can be released. In our case, the latter happened. We realized that our release cycle had gradually slipped from hours to months.

When we shifted from rapid development to a more structured product development, testing became a keyword. We began having various interdependencies within the product, and this is typical for a product that has been developed based on customer feedback. Some software companies like Microsoft use their customers to do most of the testing, but for us, this wasn't a suitable option.

The next logical step was to bundle development and bug tickets to releases. This allowed a more focused approach and the possibility for different parts of the team to focus on several things.

As the team grows and the product becomes more mature, consistency becomes an important factor all the way from UI/UX elements to the programming style.

At this stage, it is recommended to introduce code reviews. This means that the developers work in pairs on every development or bug ticket, where one developer writes code and a team member reviews the code. It is natural to add testing for each feature during this stage before the code gets merged to the main branch.

Usually, the product is so widely used in this stage that it is recommended to launch test applications that work against the production back end which can be used for internal testing.

During the process, we have also launched a set of subprocesses such as time-tracking and small tasks.

Throughout the project, communication has been the key element to successful teamwork. We communicate in context. Each release or development task is its own channel that logs all changes and allows everyone involved to communicate efficiently.

While developing a communication tool for teams, we also went deep into how different methods of communication can be applied. The below is an illustration of how we treat different types of issues under varying levels of stress.