Introduction
Over the past 15 years of development, first as an engineer and then as an engineering manager, I have had to deal with numerous technical decisions. Some of them allowed the team to accelerate incredibly and gave the company a good boost. Others, however, hindered the development process, even though they initially seemed quite reasonable. With the passage of time, it is clear: today’s architectural and technological choices directly affect the company’s agility and rate of growth in the future. In this post, I will look at some practical examples, describe how the various choices affected the key metrics, what are the most typical errors, and how to prevent them.
Investment in Development Infrastructure
As development and product teams grow, the same system problems begin to emerge. In almost all teams, these same issues, such as logging, testing, CI/CD setup, are solved differently, and this over time leads to duplication and fragmentation of work. Without deliberate effort to eliminate such repetitions, much optimization potential can be wasted. Sharing common work in one place as a reusable component or infrastructure service would usually yield significant improvement in development speed. But designing such solutions is another type of thinking: it is always a more involved problem to resolve than a specific problem “here and now.” It is not always clear at first glance whether an infrastructure project will be useful. Its effect can be assessed only after some time passes, after the complete implementation and retrospective analysis.
A prime example among the best ones is migration of one of the product platforms to microservices architecture. At the time when the process began, the core product already exceeded its maturity phase, the development team was rather big, and the business still demanded ever-faster and more complicated changes. Retaining the old architecture created constant bottlenecks and growing inter-team dependencies.
The first step was to bet on a domain separation strategy. But simply declaring the migration to microservices is not enough, without attendant infrastructure, it typically equates to mayhem. Teams began creating build procedures, logging, metrics, unit testing, integration with queues and databases in their own way. This introduced slowness of progress and increased maintenance costs.
The solution was building an independent platform of infrastructure, wherein centrally, through transparent interfaces, standard solutions to core domains, from observability to service templates, were developed and deployed. Product teams gained the ability to focus on business capabilities and deliver updates faster. The infrastructure, instead, scaled independently as a product and was then customized for other business units. Development was part-open-sourced (as https://userver.tech/) and received good word from the outside world, proving to be indirect confirmation of the greatness of the chosen architectural decisions.
Completely ignoring development infrastructure is one of the most dangerous mistakes, especially during scaling. When the team is small and the product is relatively straightforward, the absence of a shared technical base may not be a problem. But as the code base grows and more people join, the same solutions implemented in different ways begin to accumulate. This causes technical debt, makes maintenance harder, and slows down delivery. Without investment in common components and tooling, it is a chaotic process to scale the team with rising costs.
Technology Stack Selection
Technology stack selection is one of those decisions whose consequences take some time to come true but have an impact all the way through the entire product life cycle. In the SupportAI project, started as an internal one for customer support automation, popular and user-friendly Django tech was selected initially. It assisted us in quickly building a prototype, testing hypotheses, and deploying the solution. Django wasn’t part of officially supported technologies, but the team was granted enough independence to make an independent decision.
When SupportAI was identified as transitioning from being an internal tool to a sellable product to outside customers, the team was faced with having to make a change to a better stack for scale. One candidate was an in-house microservices framework that was being actively maintained by the company. It had its own support team that provided assistance and took development requests.
Migration took about a month, the prototype had already gathered much logic that required redoing. But ultimately, it proved to be the right decision. The team stopped spending time on the typical things such as parameter validation, logging, monitoring, or test frameworks. It was already implemented and kept in good shape. Moreover, the switch to the new stack introduced structure that enabled microservices-based architecture construction without the agonizing monolith split that most projects encounter in the later stages.
The main benefit, the team was able to focus on business rules and domain specifics, making product development and market entry occur sooner within the required timelines. The SupportAI experience confirmed that in choosing the technology stack, not only is convenience in the short term and sometimes in the future useful but also the ability of the solution to support product and team expansion in the long term.
The Role of Lead Engineers in Technology Strategy
To be effective, long-term technical decisions must be authored and marketed by experienced developers. Only mature engineers who have navigated dozens of real projects and already possess experience with the consequences of architectural decisions can truly justify the requirement for large technical efforts.
In contrast to product managers, who typically lack an engineering background, they can see the risks and potential worth of such solutions on the system level. And, at the same time, a decent engineer-leader does not become detached from code: they remain engaged in development, constantly code, review, and participate in RFC document discussions. Their knowledge of architecture is not built according to an abstract model, but by actual experience with the project state.
Meanwhile, any technical effort should be purposeful in relation to business objectives. It may be speeding up feature time-to-market, decreasing maintenance expenses, or automating processes. A successful lead engineer always keeps in mind the metric for which a specific architectural solution is being applied. Architecture for architecture’s sake does not work, only the synergy between technical expertise and business context yields lasting results.
Conclusion
The examples given in the article are not hypothetical, these are real cases that I had to work on. At the beginning, it is unclear what solution will work in the future. There is typically not enough data, you can’t test an experiment fully, and implications surface only after several months or years. But it is precisely such decisions, on platform, architecture, stack selection, that make team longevity and product development speed seal their destiny. It’s worth it for companies to have experts with the same level of experience. Their expertise allows for well-informed decision-making and the creation of the fundamentals of sustainable growth, not only short-term but also years later.
