Bringing an outsourced development in-house
While rebuilding their platform from the ground up, our partner needed us to ensure their in-house team could maintain the new version independently. These were the key actions we took to comply with this request.
Adam T.Our partner had everything in its power to bring their decade-old web-based platform in-house. They had the talent but needed to gain the required skills to achieve it independently. Besides migrating their legacy system, we played an essential role in ensuring the team could move forward with the development in the future without needing contractors.
Strategic dependency
One of the main reasons behind this change was lowering development costs but, most importantly, reducing cycle time since our partner was responsible for developing all client applications.
In-house development not only reduces costs but gives companies complete control over technological decisions, enabling faster update iterations and a better experience for the end users.
In the case of their current contractor, communication was slow, causing delayed updates. The estimates for new feature requests were often unreasonably high, and sometimes they even got rejected, shifting the responsibility to our partner to solve their issues alone using an alternative solution.
They were ready to take over the development from their current maintainers. Since they already had ongoing development projects, they had almost everything they needed. They had a CTO, project managers, developers, and quality assurance. However, they lacked the required skills to design and migrate such a large web-based infrastructure.
In addition to architecting and developing their new platform, our task was to provide their team with everything they needed to maintain it independently following our one-year collaborative work.
Showing the ropes
Besides the implementation, we worked hard every day since day one to prepare the in-house team for the time we were no longer available.
Gaining new skills is a natural part of any complex project, but distributing this knowledge among team members needs extra care to guarantee the project's longevity.
We applied the following tactics to leave a confident and capable team as the sole maintainer of the renewed platform.
Shadowing
We invited multiple members from the in-house team to early-stage meetings even if they did not contribute to the subject. These observations helped them understand our thought process regarding planning new features, their place in the system, and their impact on architecture or security.
Roadmapping
Setting a development roadmap the team is most comfortable with was crucial for the project's success. While it may sound obvious that we started our collaborative work on the backend API instead of the frontend client application, the deciding factor was that we wanted to start with the technologies that the development team was most comfortable with.
The subjects of modern frontend frameworks and any related technology were new for the in-house team, but they had previous experience with our chosen backend technology, namely .NET and C#.
After LevooLabs laid the foundation for the new backend, we started working together on smaller tasks, gradually increasing the complexity.
When a new type of task arose, LevooLabs always focused on implementing the first solution to display them as an example for the in-house team, where they can always return if they get stuck.
This approach contributed to team integration and reduced the in-house team's initial stress regarding the project.
Pull requests
Pull requests are not just for quality assurance.
They are powerful tools for learning from each other. Clearly, we grow by taking feedback from others, but it is also essential to examine other's work to be able to learn from them.
For this reason, we invited everyone to participate in the review process.
Regular knowledge sharing
When we work on a challenging project, we will inevitably face difficult obstacles that require research and unique solutions. When someone on the team had a similar experience, we scheduled a meeting (usually on Friday afternoons) where they could share their findings regarding their problem.
Having these sessions helps distribute knowledge among team members, making them more competent in the project while also making the presenter closer to an expert on the subject as they prepare for the presentation.
Documentation
We made detailed and meaningful documentation regarding our custom solutions in the form of markdown files next to the source code. This way, the documentation can be version-controlled along with the related source code, making it easily accessible to all developers involved. It also encourages the team to keep the documentation up to date.
This documentation proved great later in the development when we had to onboard new team members.
Crash course
Since the team had never worked with modern frontend technologies and declarative rendering, we decided to give them a week-long crash course about these subjects.
We started with Vanilla JavaScript, followed by the basic, then the advanced subjects of Vue.js. Each day, the team got example tasks relating to the actual topics so they could practice what they learned that day.
On the final day, we had an 'exam' where each person had to work independently in a given timeframe to solve a complex application, putting their knowledge to the test.
On-demand meetings
Anytime someone got stuck on a problem in the early stages of development, we never hesitated to jump into a one-on-one meeting to help them solve their issue.
As time went on, we tried to encourage them to try solving their issues independently and only gave advice or hints to build up confidence for the time when we were no longer available.
Regaining control
Together, we established a software development methodology that suits them best, which they have since applied to other in-house projects as well.
Since the grand release of their new platform, we have occasionally teamed up to help with important feature updates like the integration with Hungary's National eHealth Infrastructure (EESZT). As time passes, their team becomes increasingly confident in their craft, and they need less and less help from our end.
Finally, as planned, our partner has complete control over its intellectual property. Throughout the development process, they acquired all the necessary skills and knowledge to support their platform in the future.
As more companies recognise the strategic value of in-house development, this case can serve as a blueprint to help teams take full ownership of their technological assets.
