Situation: An organization operated a monolith in Ruby on Rails (700 APIs) to support operations in a warehouse. The organization planned to expand globally, and this monolith was not scalable anymore.
Our Approach: After analyzing the problem deeply, and understanding all the key processes in the system, we used proven techniques to come design a service oriented architecture. We incrementally developed the required services and data stores, and use a fig-tree pattern to migrate clients away from the monolith.
Situation: With hundreds of thousands of financial transactions at an e-commerce giant, it was necessary to automate risk assessment and challenge potential fraudulent transactions with AI.
Our Approach: After understanding the variables that indicated fraudulent behavior, we built and trained a random forest based AI model and effectively integrated it in the payment flow. This integration was reusable across all devices and surfaces. We measured the necessary data to improve the model over time, achieving an accuracy for fraud detection of >80%.
Situation: Amazon, the e-commerce giant, planned to use robotics in Amazon Fresh fulfillment centers. The warehouse management systems, specifically systems responsible for task management, at the time were not scalable to operate robots.
Our Approach: We analyzed industry standards, connected with robot providers to fully understand the data flow and requirements. We then developed a concept and prototype service that made task management agnostic to the underlying actor (whether human or robot), opening the doors for cost savings of millions of dollars annually.
Situation: To scale globally, an organization had the requirement to deploy their services in additional 4 data centers on the planet to keep data and services close to their customers.
Our Approach: At the time, the services were operated on-premise or in local data centers. We developed a concept and aligned with leadership that targeted to move services to the AWS cloud. We took an incremental approach, at which we containerized existing services first and deployed them on simple cloud components, before refactoring many of the services to more appropriate underlying cloud infrastructure (such as AWS Lambda and Fargate).
Situation: An organization built a product called AirborneRF, a service that allowed to visualize mobile connectivity in the sky to determine connectivity for automated drone flights.
Our Approach: We came in as full stack product developers. As such, we quickly ramped up on various technologies, and worked on backend APIs, computation pipelines and an AngularJS frontend application.
Situation: A team of 6 software engineers constantly under-estimated features, leading to frequent delays in deliveries.
Our Approach: This team tried to speed up development velocity by minimizing time spent on analyzing problems, finding alternative (creative) solutions and aligning with dependencies. Our coaching focused on strategic but high velocity problem solving to re-balance the team, resulting in 60% more accuracy in estimates and a 30% velocity gain.
Situation: A Sr. Software Engineer on the team almost always insisted on building “the most scalable” solution from day 1, slowing down development and creating a negative team environment.
Our Approach: This software engineer had a hard time balancing speed to market with building scalable solutions. Our coaching strategy focused on pragmatic problem solving, at which the engineer learned to look at technical problems from multiple perspectives. As a result, he changed his approach to still come up with long-term, scalable approaches, but also proposed multiple iterations until the end-state is reached.
Situation: Two different software engineering teams with dependencies on each other were often mis-aligned on technical details and timelines, leading to frequent delays.
Our Approach: Even the most senior engineers on those teams were primarily focused on their architecture, and their team’s problems. We focused our coaching strategy towards taking ownership of problems at a broader scale (beyond the team boundaries). As a result, the most senior engineers on both teams frequently aligned, and came up with the right processes to guide their teams towards well aligned solutions, achieving a 25% velocity increase.
Situation: A product owner continued to be negatively surprised of a team’s delivery during bi-weekly demos, leading to frequent re-work of features.
Our Approach: The root cause of this problem was missing communication (both written and verbal) between the team and their stakeholders. Our coaching strategy focused on gaining business and customer understanding, leading software engineers towards facilitating healthy discussions with stakeholders to clarify requirements fully. As a result, the team not only exceeded expectations at demos, they also achieved a 20% velocity gain.
Whether you'd like to know more about our experience and services, or chat with us about your challenges - shoot us an email or give us a call!
cell: +43 664 131 8868 email: georg@devmavericks.com
DevMavericks -- Georg Hennerbichler
Copyright © 2025 DevMavericks – all rights reserved.
Disclosure acc. to § 25 MedG - Responsible for the content of this website: Georg Hennerbichler, georg@devmavericks.com, Austria