Uniting different skill sets, experiences, and perspectives through engineering collaboration is a process that brings complex challenges, but also can forge innovation through synergy if done correctly. Atlantbh had a chance to work on such a project where close day-to-day collaboration with an external development team was needed for successful delivery. In this case study, we’ll explore how we collaborated to update the system’s architecture, handle changes in technology and onboard to Elixir, and navigate the business landscape while nurturing a partnership built on adaptability and shared knowledge.

The problem

The client had been developing a backend system for a number of years, for which they realized that the initial architecture and application model were no longer suitable to their current needs. As the business was spreading, this implicated a rise in the number of end-users and different use cases which haven’t been foreseen and didn’t fit in the current architecture. To bypass system limitations, numerous temporary solutions needed to be implemented to address these gaps. Unfortunately, when the system outgrows its initial architecture and temporary solutions come into play for a longer period, at some point the development team finds itself fully consumed with fixing production issues that arise due to this very situation, as was the case with this particular project.

Consequently, a decision has been made to rewrite the old backend system using a more appropriate tech stack and to create a flexible model capable of accommodating all use cases. In search of a partner, the client was looking for someone who would invest considerable time and expertise in analyzing the requirements, learning both the business and new technology, collaborating closely with the internal technical team, and successfully integrating into the existing ecosystem.


During the initial weeks, we devoted time to gathering and analyzing requirements. Additionally, we have invested efforts in familiarizing ourselves with the legacy application, and the whole ecosystem into which our service would integrate, addressing technical challenges, and gaining an understanding of the client’s expectations.

The team was faced with the following challenges:

  • New technology stack – Elixir. The transition from Java (our usual choice of technology) to Elixir required learning and adapting to the new technology and frameworks. We did have expertise in Ruby which is a similar programming language, but not with the particular one. What also helped is the fact that our software engineers are full-stack engineers, and are used to adopting different technology stacks.
  • Event-driven model approach. Adopting an event-driven model for software development introduced a paradigm shift in our development approach. It already helped that we had expertise in event-based communication, designing asynchronous workflows, etc.
  • Complex ecosystem and business logic. Our software was part of a larger ecosystem, including multiple interconnected services that shared data and events. We did have experience in working with different teams in large ecosystems, but this one was quite different in size and complexity. We had to find the best collaboration model which would work for both teams, to understand dependencies and common practices. 


Our journey with Elixir

The client offered assistance in knowledge transfer and onboarding to the new technology stack to address these challenges. We conducted knowledge transfer and pair programming sessions, sharing expertise and guiding us to avoid common pitfalls when starting with this stack. The team was grateful for such an opportunity, which leveraged our efforts later. We continued independently familiarizing ourselves with Elixir, and started the development of standalone features.

Collaboration model

The chosen collaboration model involved regular communication and coordination between the teams:

  • Daily sync calls were conducted, with representatives from both teams sharing updates and discussing progress. 
  • Weekly sync meetings between the product manager, technical lead, and our service lead helped align expectations and address any concerns. 
  • Planning and breakdown sessions were organized as needed to ensure efficient project management and decision-making. 
  • All parties were open to constructive feedback, which helped us overcome challenging situations and manage expectations.

Development and delivery

In collaboration with a product manager and technical lead, we defined the scope for the initial version of the product, ensuring it would provide immediate value to the users. Our team was responsible for the backend service which would replace a specific segment of the old system.

As the business logic defined was unlikely to undergo significant changes in the future, we have agreed on the approach that involved implementing the defined functionalities one by one, in detail, incorporating comprehensive logic and thorough unit and integration testing. To document the system behavior, we adopted the Gherkin language which was already being used in the rest of the ecosystem, ensuring clarity and future stability. While this approach demanded more time for development and delivery upfront, the client was aware of the long-term benefits of investing in a solid foundation.

As of now, our service has been successfully deployed in production, catering to a small user base. By diligently gathering feedback and continuously adapting to improve our service, we are moving on our way to transition to larger user groups. The feedback received thus far validated the stability and reliability of our core logic. 


Each new project presents its unique challenges, but a willingness to embrace new approaches and technologies brings significant advantages to software companies, broadening their horizons and knowledge base. 

Throughout this endeavor, our team demonstrated key characteristics that played an essential role in a successful partnership with our client. Our expertise in software delivery, profound technical knowledge of design principles and software engineering, problem-solving skills, and readiness to embrace new methodologies and feedback were instrumental in achieving positive outcomes.

Technology stack: Elixir, Phoenix, HTML, CSS, Rabbitmq, Gherkin
Project duration: 1+ year

redesign candidate
BlogProduct Management
November 22, 2023

Finding the Ideal Redesign Candidate

When discussing software, arguments on what is visually and functionally "good" can be subjective. While UI/UX principles offer guidance, recognizing the need for a redesign goes beyond design standards. Decisions on starting a redesign are made based on the different perspectives of Engineering, Product Management and UI/UX, with additional factors…

Want to discuss this in relation to your project? Get in touch:

Leave a Reply