# Drupal Configuration Drift in Multi-Team Platforms: Why Release Confidence Erodes Over Time

Sep 18, 2024

Drupal platforms rarely become unsafe to release because of a single bad deployment. More often, release confidence erodes gradually as configuration changes spread across environments without clear ownership, promotion rules, or validation controls.

This article looks at **Drupal configuration drift** as an operating model problem. It explains how multi-team programs can restore release confidence by defining config boundaries, enforcing environment discipline, and treating validation as part of platform governance rather than an optional technical cleanup task.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240918-drupal-configuration-drift-in-multi-team-platforms "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240918-drupal-configuration-drift-in-multi-team-platforms "Summarize this page with Claude")[](https://www.google.com/search?udm=50&q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240918-drupal-configuration-drift-in-multi-team-platforms "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240918-drupal-configuration-drift-in-multi-team-platforms "Summarize this page with Grok")[](https://www.perplexity.ai/search/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20240918-drupal-configuration-drift-in-multi-team-platforms "Summarize this page with Perplexity")

![Blog: Drupal Configuration Drift in Multi-Team Platforms: Why Release Confidence Erodes Over Time](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20240918-drupal-configuration-drift-in-multi-team-platforms--cover)

Large Drupal programs often start with good intentions: a shared platform, standard release practices, and a sensible separation between development, test, and production. Over time, though, the operating reality changes. More teams touch the platform. Emergency fixes bypass the normal path. Different environments stop behaving the same way. A release that looked low risk in planning begins to feel unpredictable in execution.

That loss of confidence is frequently traced back to **Drupal configuration drift**.

In enterprise settings, drift is not just a technical mismatch between exported configuration and what exists in an environment. It is usually the visible symptom of a broader delivery problem: unclear ownership, inconsistent promotion rules, weak review discipline, and too many ways to make production state diverge from what teams think they are shipping.

The important point is that drift rarely becomes chronic because people do not know how Drupal configuration works. It becomes chronic because the platform's governance model does not consistently control how configuration is created, reviewed, promoted, and recovered.

### What configuration drift looks like in enterprise Drupal programs

In simple terms, configuration drift exists when the configuration state in one environment no longer matches the expected baseline represented by version-controlled configuration and approved promotion history.

In enterprise Drupal delivery, that can show up in several ways:

*   a module is enabled directly in one environment but never properly promoted
*   content model changes exist in QA but not in production, or vice versa
*   site settings are updated manually during an incident and never reconciled
*   a multisite estate has local exceptions that are poorly documented and difficult to validate
*   teams believe they are releasing code, but the real production outcome depends on hidden environment differences

The operational symptom is not just inconsistency. It is uncertainty.

Teams stop being able to answer basic release questions with confidence:

*   What exactly is changing?
*   Which environments are still aligned?
*   Can we promote this safely?
*   If something fails, do we know whether the cause is code, config, content, or environment state?

Once those questions become hard to answer, every release carries more coordination cost than it should.

### Why multi-team delivery and emergency fixes make drift worse

Single-team Drupal implementations can experience drift, but multi-team platforms amplify it.

Different delivery squads may own separate features while sharing parts of the same configuration surface. Central platform teams may control hosting, deployment tooling, or security baselines, while product teams manage day-to-day changes. Agencies, internal developers, and operations staff may all have some level of administrative access.

That shared operating model creates several common failure patterns.

First, more teams means more parallel change. Even when each team follows reasonable practices, coordination gaps can produce collisions or out-of-sequence promotions.

Second, emergency fixes often bypass normal promotion paths. During an incident, restoring service is the right priority. The problem comes afterward, when manual changes are not reconciled into source control or not clearly attributed to an owner.

Third, enterprise environments are rarely identical in all the ways teams assume. Differences in modules, permissions, integrations, environment variables, or deployment timing can mask drift until a release window exposes it.

Finally, the longer a platform operates without strong controls, the more likely teams are to normalize the drift. Workarounds become accepted practice. People rely on tribal knowledge. Releases still happen, but confidence depends more on experienced individuals than on repeatable system behavior.

### The boundary between content, configuration, code, and environment state

A major reason drift becomes difficult to control is that enterprise teams often blur the boundary between different types of platform state.

In Drupal, release safety improves when teams treat the following as distinct concerns:

*   **Code**: custom modules, themes, patches, and application logic
*   **Configuration**: content types, fields, views, workflows, permissions, display settings, and other managed platform behavior
*   **Content**: editorial entries, media, taxonomy terms, and business data created through normal platform use
*   **Environment state**: secrets, infrastructure settings, external integration details, cache layers, and hosting-specific controls

When these categories are mixed operationally, delivery risk increases.

For example, teams may treat a production-only manual setting as if it were harmless environment administration when it actually changes application behavior. Or they may assume a configuration change is equivalent to content entry because it was made through the UI. Or they may promote code assuming the configuration dependency is already present somewhere else.

The practical consequence is confusion about what belongs in version control, what should move through promotion workflows, what should remain environment-specific, and what should never be altered manually outside approved paths.

This is where governance matters more than tooling alone. Teams do not need a perfect theoretical model. They need a workable and shared one.

### Common root causes: shared admin access, inconsistent promotion paths, weak review discipline

Most long-running drift problems can be traced back to a few recurring causes.

**Shared or loosely controlled administrative access** is one of the most common. When many people can make direct changes in higher environments, local fixes accumulate faster than teams can reconcile them. Even well-intentioned users can introduce release risk if there is no clear rule for what must be changed through source control and approved promotion.

**Inconsistent promotion paths** are another major issue. If some changes move from development to test to production, while others are applied directly to QA or production, then environment history stops being trustworthy. Teams can no longer assume that a successful lower-environment test meaningfully predicts production behavior.

**Weak review discipline** also plays a large role. Configuration changes often seem small, especially when they originate in UI-based administration. But they can alter permissions, workflows, integrations, and editorial behavior in ways that are hard to unwind quickly. Without structured review, organizations underestimate the impact of seemingly minor changes.

Other frequent contributors include:

*   lack of explicit ownership for shared configuration domains
*   unclear rules for site-level exceptions in multisite platforms
*   release processes that validate code but not configuration integrity
*   no standard post-incident reconciliation step
*   inadequate change records for audit, rollback, or root-cause review

None of these are exotic failure modes. They are normal enterprise delivery risks that become more costly when the platform is shared across many teams and brands.

### How drift affects releases, incident response, and auditability

Configuration drift has a direct effect on delivery performance, but the more important issue is decision quality.

When platform state is not reliable, release planning becomes defensive. Teams add extra checks, extra approvals, and extra freeze periods because they do not trust the baseline. That can reduce immediate risk, but it also slows delivery and creates pressure for more exceptions later.

Drift also complicates incident response. If a deployment fails or behavior changes unexpectedly, teams need to determine whether the cause came from:

*   newly deployed code
*   missing or conflicting configuration
*   data conditions in production content
*   environment-specific settings or integrations

The less disciplined the platform history, the harder that diagnosis becomes.

Auditability suffers as well. Regulated or highly governed organizations often need to answer simple but important questions: who changed what, when, why, and through which approval path? Drift weakens those answers. Even if teams can reconstruct events eventually, the effort required is far higher than it should be.

This is why **enterprise Drupal release management** cannot treat configuration drift as a narrow developer concern. It is an operational integrity issue. It affects predictability, accountability, and recovery.

### Governance patterns for shared platforms and multisite estates

The best response to drift is usually not a one-time cleanup. It is a governance model that makes the desired behavior easier than the unsafe behavior.

For shared platforms and multisite estates, a few patterns are especially useful.

**Define configuration ownership boundaries.** Not all configuration should be treated as shared by default. Some areas belong to the central platform team, some to site owners, and some require joint review. Ownership should be explicit enough that teams know who approves change and who resolves conflicts. This kind of operating model work is usually part of broader [Drupal platform strategy](/services/drupal-platform-strategy).

**Separate platform standards from local variation.** In multisite environments, exceptions are often necessary. The problem is unmanaged exceptions, not exceptions themselves. Teams should document what can vary per site, what must remain standardized, and what requires architecture review before deviation. That becomes especially important in large [Drupal multisite](/services/drupal-multisite) estates.

**Limit direct change rights in higher environments.** Production access should support operations, not replace promotion workflows. This does not mean eliminating all emergency access. It means making exceptions controlled, attributable, and reconcilable.

**Create a single trusted promotion path.** Teams should know where configuration starts, how it is reviewed, which environments it passes through, and what evidence is required before release. Multiple unofficial paths are one of the fastest ways to lose release confidence.

**Use change classification.** Not every configuration change carries the same risk. A display tweak is different from a workflow or permissions change. Organizations can improve both speed and safety by defining review depth based on impact category rather than treating all changes as identical.

These patterns apply across Drupal open source and enterprise hosting models. The exact tooling may vary, but the delivery principles remain the same.

### Validation, deployment, and recovery practices that restore confidence

Once governance is clearer, teams need operational practices that make drift visible early and recovery realistic.

A strong validation approach often includes:

*   checking expected configuration consistency before release windows, not only during failed deployments
*   validating that lower environments are credible predictors of production behavior
*   flagging changes made outside normal promotion paths for reconciliation
*   reviewing high-risk configuration domains such as permissions, workflows, integrations, and shared content model structures
*   confirming that multisite exceptions are documented and still intentional

Deployment discipline matters too. Releases are safer when teams promote a known set of code and configuration together, using environment sequencing that reflects the real production path. If a platform repeatedly relies on ad hoc manual adjustments during deployment, that is usually evidence that the baseline model is incomplete or not being followed. In practice, this often points to the need for stronger [Drupal platform modernization](/services/drupal-platform-modernization) around release engineering and environment parity.

Recovery practices are equally important. Many organizations focus on how to deploy, but not on how to recover from drift when a release behaves unexpectedly. Recovery readiness usually improves when teams can:

*   identify whether the issue is baseline drift or a newly introduced defect
*   compare expected and actual configuration state quickly
*   reconcile emergency changes back into the approved source of truth
*   document incident-era exceptions so they do not become permanent hidden dependencies

The goal is not to create an overly rigid release process. It is to make safe release behavior repeatable, observable, and easier to trust.

### A phased remediation approach for teams already in drift

For teams already experiencing chronic drift, the answer is usually not a disruptive reset. A phased remediation approach is more realistic.

**Phase 1: establish visibility.** Start by identifying where drift is most damaging. Which environments are least trustworthy? Which configuration domains cause the most release friction? Which teams can currently change production state, and through what mechanisms? This phase is about creating a usable map, not assigning blame.

**Phase 2: define operating rules.** Clarify the boundaries between code, configuration, content, and environment state. Define who owns shared configuration areas. Document which changes must flow through version control and which are valid environment-specific exceptions.

**Phase 3: reduce uncontrolled access and path variation.** Tighten direct administrative rights in higher environments. Standardize promotion paths. Make emergency change handling explicit, including a required reconciliation step after the incident.

**Phase 4: improve validation and release evidence.** Add pre-release checks that verify configuration integrity and environment alignment. Require clearer evidence for high-impact configuration changes. In shared platform contexts, ensure site-level variation is reviewed against platform standards.

**Phase 5: normalize recovery and continuous governance.** Treat drift prevention as an ongoing platform operation, not a one-off project. Review incidents for process gaps. Periodically revisit ownership boundaries and exception lists. Adjust governance as the platform and team structure evolve.

This phased approach is often more sustainable than trying to solve everything with stricter tooling alone. Tooling helps, but confidence returns when teams trust the operating model around it. Programs dealing with large shared estates can see this clearly in the [Veolia](/projects/veolia-environmental-services-sustainability) example, where configuration governance and rollout control were central to stabilizing delivery.

### Release confidence improves when platform behavior becomes legible

The core problem with **Drupal configuration drift** is not merely that environments differ. It is that the platform's behavior becomes harder to explain, predict, and recover.

That is why the solution sits at the intersection of architecture, governance, and delivery operations. Teams need a shared understanding of what configuration is, who owns it, how it moves, when exceptions are allowed, and how divergence is detected and repaired.

For enterprise Drupal programs, especially those spanning multiple teams or multisite estates, this work pays off in more than cleaner deployments. It improves incident response, strengthens auditability, and restores a crucial delivery capability: the ability to release with confidence because the platform state is legible and the promotion path is trustworthy.

When that happens, configuration stops being a chronic source of uncertainty and becomes what it should have been all along: a managed part of the product delivery system.

Tags: Drupal, Drupal configuration drift, enterprise Drupal release management, Drupal config governance, multi-environment Drupal delivery, Drupal platform operations

## More on Drupal platform governance and release control

These articles extend the operating-model issues behind Drupal configuration drift, especially in enterprise and multi-team delivery. They cover multisite standardization, migration planning, and broader governance patterns that help teams reduce release risk, define ownership, and keep platform change manageable over time.

[

![How to Standardize a Drupal Multisite Platform Without Freezing Local Delivery](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20250722-drupal-multisite-standardization-without-blocking-local-teams--cover?_a=BAVMn6ID0)

### How to Standardize a Drupal Multisite Platform Without Freezing Local Delivery

Jul 22, 2025

](/blog/20250722-drupal-multisite-standardization-without-blocking-local-teams)

[

![Drupal 11 Migration Planning for Enterprise Teams](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260304-drupal-11-migration-planning-for-enterprise-teams--cover?_a=BAVMn6ID0)

### Drupal 11 Migration Planning for Enterprise Teams

Mar 4, 2026

](/blog/20260304-drupal-11-migration-planning-for-enterprise-teams)

[

![Enterprise Taxonomy Governance After Decentralized Publishing Starts to Drift](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20210518-enterprise-taxonomy-governance-after-decentralized-publishing--cover?_a=BAVMn6ID0)

### Enterprise Taxonomy Governance After Decentralized Publishing Starts to Drift

May 18, 2021

](/blog/20210518-enterprise-taxonomy-governance-after-decentralized-publishing)

## Get support for Drupal platform governance and release reliability

If configuration drift is eroding release confidence, the next step is to strengthen the platform architecture, governance model, and delivery controls behind Drupal itself. These services help define configuration ownership, standardize promotion workflows, modernize release engineering, and add the operational guardrails needed for safer multi-team delivery.

[

### Enterprise Drupal Architecture

Designing Scalable Digital Foundations

Learn More

](/services/drupal-architecture)[

### Drupal Governance Architecture

Drupal editorial workflow engineering and permissions model design

Learn More

](/services/drupal-governance-architecture)[

### Drupal Platform Modernization

Enterprise Drupal upgrade strategy for upgradeable delivery

Learn More

](/services/drupal-platform-modernization)[

### Drupal DevOps & CI/CD

Automated CI/CD Pipelines. Reliable Infrastructure.

Learn More

](/services/drupal-devops)[

### Drupal Monitoring & Observability

Prometheus Grafana Drupal monitoring with metrics, logs, and alerting

Learn More

](/services/drupal-monitoring-observability)[

### Drupal Platform Strategy

Roadmaps, governance model design, and platform decision frameworks

Learn More

](/services/drupal-platform-strategy)

## See Drupal governance in multisite and enterprise delivery

These case studies show how Drupal teams restored release confidence through stronger governance, controlled rollout patterns, and safer platform evolution. They are especially relevant for readers dealing with configuration drift, because they demonstrate how architecture, workflow controls, and validation practices reduce operational uncertainty across complex environments. Together, the case studies extend the article from diagnosis into real delivery approaches used on large multi-team Drupal estates.

\[01\]

### [VeoliaEnterprise Drupal Multisite Modernization (Acquia Site Factory, 200+ Sites)](/projects/veolia-environmental-services-sustainability "Veolia")

[![Project: Veolia](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-veolia--challenge--01)](/projects/veolia-environmental-services-sustainability "Veolia")

[Learn More](/projects/veolia-environmental-services-sustainability "Learn More: Veolia")

Industry: Environmental Services / Sustainability

Business Need:

With Drupal 7 reaching end-of-life, Veolia needed a Drupal 7 to Drupal 10 enterprise migration for its Acquia Site Factory multisite platform—preserving region-specific content and multilingual capabilities across more than 200 sites.

Challenges & Solution:

*   Supported Acquia Site Factory multisite architecture at enterprise scale (200+ sites). - Ported the installation profile from Drupal 7 to Drupal 10 while ensuring platform stability. - Delivered advanced configuration management strategy for safe incremental rollout across released sites. - Improved page loading speed by refactoring data fetching and caching strategies.

Outcome:

The platform was modernized into a stable, scalable multisite foundation with improved performance, maintainability, and long-term upgrade readiness.

“As Dev Team Lead on my project for 10 months, Oleksiy (PathToProject) demonstrated excellent technical skills and the ability to handle complex Drupal projects. His full-stack expertise is highly valuable. ”

Laurent PoinsignonDomain Delivery Manager Web at TotalEnergies

\[02\]

### [United Nations Convention to Combat Desertification (UNCCD)United Nations website migration to a unified Drupal DXP](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[![Project: United Nations Convention to Combat Desertification (UNCCD)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-unccd--challenge--01)](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[Learn More](/projects/unccd-united-nations-convention-to-combat-desertification "Learn More: United Nations Convention to Combat Desertification (UNCCD)")

Industry: International Organization / Environmental Policy

Business Need:

UNCCD operated four separate websites (two WordPress, two Drupal), leading to inconsistencies in design, content management, and user experience. A unified, scalable solution was needed to support a large-scale CMS migration project and improve efficiency and usability.

Challenges & Solution:

*   Migrating all sites into a single, structured Drupal-based platform (government website Drupal DXP approach). - Implementing Storybook for a design system and consistency, reducing content development costs by 30–40%. - Managing input from 27 stakeholders while maintaining backend stability. - Integrating behavioral tracking, A/B testing, and optimizing performance for strong Google Lighthouse scores. - Converting Adobe InDesign assets into a fully functional web experience.

Outcome:

The modernization effort resulted in a cohesive, user-friendly, and scalable website, improving content management efficiency and long-term digital sustainability.

“It was my pleasure working with Oleksiy (PathToProject) on a new Drupal website. He is a true full-stack developer—the ideal mix of DevOps expertise, deep front-end knowledge, and the structured thinking of a senior back-end developer. He is well-organized and never lets anything slip. Oleksiy understands what needs to be done before being asked and can manage a project independently with minimal involvement from clients, product managers, or business analysts. One of the best consultants I’ve worked with so far. ”

Andrei MelisTechnical Lead at Eau de Web

\[03\]

### [Copernicus Marine ServiceCopernicus Marine Service Drupal DXP case study — Marine data portal modernization](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[![Project: Copernicus Marine Service](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-copernicus--challenge--01)](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[Learn More](/projects/copernicus-marine-service-environmental-science-marine-data "Learn More: Copernicus Marine Service")

Industry: Environmental Science / Marine Data

Business Need:

The existing marine data portal relied on three unaligned WordPress installations and embedded PHP code, creating inefficiencies and risks in content management and usability.

Challenges & Solution:

*   Migrated three legacy WordPress sites and a Drupal 7 site to a unified Drupal-based platform. - Replaced risky PHP fragments with configurable Drupal components. - Improved information architecture and user experience for data exploration. - Implemented integrations: Solr search, SSO (SAML), and enhanced analytics tracking.

Outcome:

The new Drupal DXP streamlined content operations and improved accessibility, offering scientists and businesses a more efficient gateway to marine data services.

“Oleksiy (PathToProject) is demanding and responsive. Comfortable with an Agile approach and strong technical skills, I appreciate the way he challenges stories and features to clarify specifications before and during sprints. ”

Olivier RitlewskiIngénieur Logiciel chez EPAM Systems

\[04\]

### [Bayer Radiología LATAMSecure Healthcare Drupal Collaboration Platform](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[![Project: Bayer Radiología LATAM](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-bayer--challenge--01)](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[Learn More](/projects/bayer-radiologia-latam "Learn More: Bayer Radiología LATAM")

Industry: Healthcare / Medical Imaging

Business Need:

An advanced healthcare digital platform for LATAM was required to facilitate collaboration among radiology HCPs, distribute company knowledge, refine treatment methods, and streamline workflows. The solution needed secure medical website role-based access restrictions based on user role (HCP / non-HCP) and geographic region.

Challenges & Solution:

*   Multi-level filtering for precise content discovery. - Role-based access control to support different professional needs. - Personalized HCP offices for tailored user experiences. - A structured approach to managing diverse stakeholder expectations.

Outcome:

The platform enhanced collaboration, streamlined workflows, and empowered radiology professionals with advanced tools to gain insights and optimize patient care.

“Oleksiy (PathToProject) and I worked together on a Digital Transformation project for Bayer LATAM Radiología. Oly was the Drupal developer, and I was the business lead. His professionalism, technical expertise, and ability to deliver functional improvements were some of the key attributes he brought to the project. I also want to highlight his collaboration and flexibility—throughout the entire journey, Oleksiy exceeded my expectations. It’s great when you can partner with vendors you trust, and who go the extra mile. ”

Axel Gleizerman CopelloBuilding in the MedTech Space | Antler

“Oleksiy (PathToProject) is a great professional with solid experience in Drupal. He is reliable, hard-working, and responsive. He dealt with high organizational complexity seamlessly. He was also very positive and made teamwork easy. It was a pleasure working with him. ”

Oriol BesAI & Innovation (Discovery, Strategy, Deployment, Scouting) for Business Leaders

\[05\]

### [DeprexisDrupal Performance Stabilization & Secure eCommerce Payment Workflows](/projects/deprexis-digital-mental-health-platform "Deprexis")

[![Project: Deprexis](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-deprexis--challenge--01)](/projects/deprexis-digital-mental-health-platform "Deprexis")

[Learn More](/projects/deprexis-digital-mental-health-platform "Learn More: Deprexis")

Industry: Digital Health / Mental Health

Business Need:

The Deprexis mental health digital platform on Drupal required stabilization, faster performance, and a secure ecommerce payment workflow to support online services. The solution needed to meet strict reliability and security expectations common for digital healthcare products.

Challenges & Solution:

*   Critical performance bottlenecks were identified and resolved with caching and rendering optimizations. - A secure eCommerce/payment module was implemented with ABank integration for online checkout. - Automated regression coverage was introduced to protect sensitive order workflows and reduce release risk. - Quality gates were improved through test-driven delivery and repeatable validation in CI.

Outcome:

The platform was stabilized, performance was improved, and secure checkout workflows were delivered with strong automated coverage to reduce operational and compliance risks.

![Oleksiy (Oly) Kalinichenko](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_200,h_200,g_center,f_avif,q_auto:good/v1/contant--oly)

### Oleksiy (Oly) Kalinichenko

#### CTO at PathToProject

[](https://www.linkedin.com/in/oleksiy-kalinichenko/ "LinkedIn: Oleksiy (Oly) Kalinichenko")

### Do you want to start a project?

Send