A Senior Software Engineer at one of the world’s leading technology consultancies shows how treating architecture as a financial solution helps companies prevent downtime losses, cut delivery costs, and sustain growth
In 2025, the financial stakes of technology downtime have never been clearer. A global survey of nearly 1,000 executives found that every single respondent experienced outage-related revenue losses in the past year, with some reporting damages exceeding $1 million per incident. On average, organizations suffered 86 hours of downtime annually, and with studies estimating the cost of downtime at $9,000 per minute, even minor disruptions can cascade into crippling financial consequences.
That’s why, according to Dmitrii Kuzmin, a 2025 jury member of the Cases & Faces Awards and the winner of the National Business Awards as the Software Engineer of the Year, engineers who design resilient architectures are no longer just developers but financial guardians. While working for 12 STOREEZ — a rapidly scaling international fashion retailer known for its vertically integrated production and online-first business model — he led the technical migration and redesign of the user interface of its Warehouse Management System (WMS), the platform that coordinates all warehouse operations from order processing to shipment. The goal was to migrate from a legacy Vue.js-based application to Angular without interrupting daily logistics. His solution was unconventional: Dmitrii rewrote the WMS UI, embedding new modules written in Angular into the Vue.js application page by page, leveraging feature toggle with an automatic fallback. If the Angular server ever failed, the system seamlessly reverted to the Vue.js interface, ensuring the warehouse never stopped processing orders. This architectural safeguard eliminated downtime-induced losses and helped maintain an up to 97% on-time-and-in-full (OTIF) fulfillment rate, one of the highest in retail logistics.
We spoke with Dmitrii about how such architectural precision turns code into profit—and why technologies like monorepos, micro-frontends, and automation frameworks are quietly becoming the new engines of business value.
— Dmitrii, the latest industry reports show that every major company has experienced downtime-related losses lately. Why has system resilience become such a critical business factor, and how do engineering teams typically underestimate its financial impact?
Downtime is one of those things that everyone knows is expensive but few actually quantify until it happens. For example, a few hours of system outage in retail can block order processing, delay shipments, and trigger refund chains — all of which accumulate into massive losses. The reason it’s underestimated is that stability doesn’t have an immediate “wow effect” like new features do. But in practice, resilience is what keeps the business profitable. Companies now realize that the real value of engineering isn’t just to build, but to keep the system continuously available. That’s why architectural decisions are increasingly seen as financial ones.
— So when we talk about architecture as a financial safeguard rather than just a technical choice, what does that mean in practical terms for you as a software engineer?
It means thinking in terms of business continuity, not just clean code. When I design a system, I ask: what happens if this service goes down? How fast can it recover? Can another part of the system take over automatically? Those questions lead to architectural decisions, like isolation between components or fallback mechanisms, that directly translate into cost savings. Essentially, you build not just for functionality, but for resilience under failure, and that’s what prevents companies from losing revenue when something inevitably goes wrong.
— You’ve seen firsthand how these risks play out in business-critical systems. At 12 STOREEZ, a fast-scaling fashion retailer, you led the migration of its warehouse management platform. What made that project especially vulnerable to downtime, and how did you approach minimizing the risk?
The warehouse system was at the operational core of the company — every order, shipment, and stock update passed through it. The main risk came from the migration itself: we were moving from one stack (Vue.js + Python) to another (Angular + NestJS), while the warehouse had to stay fully operational. I approached it as a business continuity problem, not just a technical upgrade. A ‘big bang’ migration was not an option. That’s why I architected a resilient hybrid model using Module Federation to load new Angular features as Web Components into the Vue.js host. This allowed us to deploy the new stack incrementally, ensuring a safe coexistence.
— That hybrid model you architected: loading Angular Web Components into a Vue.js host, is a non-trivial solution. What specific mechanism ensured this, as you call it, “safe coexistence” and made it worth the complexity?
Because in business terms, operational stability is more valuable than engineering elegance. A standard MFE approach still has risks: if a new Angular “remote” fails to load or its Web Component fails to initialize, the user’s workflow breaks.
The mechanism that ensured safety was a controlled, component-level fallback I engineered. It was our insurance policy. The Vue.js host was designed to catch any such error during initialization. If a new Angular component failed, the system wouldn’t crash; it would instantly revert to rendering the stable, legacy Vue.js component for that specific feature. Operations continued, workers didn’t notice, and the company avoided disrupting logistics. It was this fallback that transformed a high-risk migration into a zero-risk, incremental rollout.
— At KODE, a technology company known for developing large-scale government platforms in healthcare and education, what did you learn about designing infrastructure that must remain stable for millions of daily users?
In this company, I developed and optimized front-end architecture for key public modules of citywide digital systems that support healthcare and education for millions of residents — platforms where people schedule check-ups, view medical results, and track school progress. That experience taught me what “mission-critical” really means. When a system failure can delay a doctor’s appointment or disrupt access to a child’s progress report, reliability becomes not just a feature but a civic responsibility. Since then, I’ve treated architectural stability as a design objective — something you plan for from the first line of code.
— Such platforms, built not to generate revenue but to deliver public value, became part of the city’s digital backbone, serving millions of residents and students. What kind of “return on investment” do you see in projects of that scale, and how has that experience influenced how you now define value in commercial systems?
The return wasn’t financial — it was systemic. When a citizen can schedule a doctor’s appointment in seconds or access school results without queues or paperwork, that reliability becomes the product. For engineers, it’s deeply motivating to see technology directly improve everyday life. That perspective stayed with me. In business projects, I still measure success not only in profits or delivery speed but in trust metrics — how many failures were prevented, how fast the system recovers, how confidently users rely on it. Whether it’s public infrastructure or enterprise software, architecture pays off when people stop noticing it — when it just works.
— You also introduced automation through Angular schematics built with Nx, and previously used PlopJS for code generation. How did these tools reshape the team’s workflow?
Automation became a multiplier. Instead of manually wiring up boilerplates for new components, routes, or Redux stores, engineers could generate ready-to-use modules in seconds. It eliminated repetitive work and ensured every new feature followed the same architectural rules. That consistency raised the overall quality and reduced onboarding time for new developers. Essentially, I turned recurring tasks into templates, freeing the team to focus on real engineering challenges rather than setup routines.
— You’re known for enforcing strict code-review standards and adherence to Angular best practices. From your perspective, how does that discipline translate into financial value for a company?
Clean architecture and consistent reviews are like preventive maintenance in manufacturing: they reduce the chance of expensive breakdowns later. Every shortcut today becomes technical debt tomorrow. By keeping the codebase clean, you lower long-term maintenance costs and make scaling predictable. In financial terms, that’s an insurance policy against future inefficiency. Companies that ignore it end up spending multiples more fixing accumulated issues later.
— What’s the single highest-value concept you focus on when teaching others?
I emphasize architectural thinking, understanding why a system is built a certain way, not just how to code it. Once a developer starts asking, “What business problem does this solve?”, their decisions become more strategic and their code naturally more valuable.
I saw how this mindset can transform a team in practice: after several mentoring sessions and a constant code review process, developers began writing cleaner, more maintainable code, and the overall number of bugs dropped noticeably. For me, mentoring isn’t just about teaching syntax or frameworks. Actually, it’s building an engineering culture where every line of code contributes to long-term reliability and measurable business impact.
— This year, you also joined the jury of the Cases & Faces awards — a respected industry competition where leading experts evaluate the business results behind digital and IT innovations. What recurring trends did you observe — and what do they reveal about how the industry now treats architecture as an investment rather than just an engineering task?
Serving on the jury gave me a good overview of how companies link technology to value. The strongest cases approached architecture not as a technical artifact, but as a long-term asset — something that reduces operational risk, saves costs, or enables faster scaling. I also noticed a shift: fewer projects chase novelty for its own sake. Teams increasingly see architecture as part of financial strategy, focusing on reliability, maintainability, and measurable returns. It’s a healthy trend — engineering maturity is finally being judged in economic terms.
— After working on systems where a few hours of downtime could cost a company millions, do you ever feel personal pressure knowing how directly your code affects business performance?
Of course. But I see that pressure as a form of responsibility, not stress. When you realize that a single architectural mistake can halt production or cause financial loss, it changes your attitude toward engineering. You start treating every line of code as part of a living business process, not just a technical task. For me, that awareness became motivating: it reminds me that what we build as engineers has real-world consequences. And that’s what keeps me focused on quality, because in the end, stability isn’t just about systems; it’s also about the trust people place in them.
