# Gutenberg Block Governance for Enterprise WordPress: How to Prevent Editorial Freedom from Becoming Template Drift

Jun 21, 2022

By Oleksiy Kalinichenko

Gutenberg works well at enterprise scale only when teams treat it as part of the platform operating model, not just a modern editing interface. A governed block model helps define who owns blocks and patterns, where flexibility is allowed, how templates are constrained, and how content remains stable as the platform evolves.

This article explains how to approach **Gutenberg block governance** as an architectural discipline: balancing editorial autonomy with design consistency, engineering maintainability, and safe release practices.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20220621-gutenberg-block-governance-for-enterprise-wordpress-platforms "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20220621-gutenberg-block-governance-for-enterprise-wordpress-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%2F20220621-gutenberg-block-governance-for-enterprise-wordpress-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%2F20220621-gutenberg-block-governance-for-enterprise-wordpress-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%2F20220621-gutenberg-block-governance-for-enterprise-wordpress-platforms "Summarize this page with Perplexity")

![Blog: Gutenberg Block Governance for Enterprise WordPress: How to Prevent Editorial Freedom from Becoming Template Drift](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20220621-gutenberg-block-governance-for-enterprise-wordpress-platforms--cover)

Enterprise WordPress teams often adopt Gutenberg with the right intent: give editors more flexibility, reduce custom page-builder debt, and align content creation more closely with a design system.

But once multiple business units, content teams, agencies, or product teams are publishing at scale, Gutenberg can expose a different problem. The editor becomes a broad composition surface. Without clear guardrails, that surface can produce inconsistent layouts, one-off patterns, duplicated blocks, and fragile content that becomes difficult to maintain over time.

[Are architecture decisions getting harder to defend?Run a quick WordPress Health Check→](/wordpress-health-check?context=architecture#run)

That is why **Gutenberg block governance** matters. This is not mainly a question of whether editors should be trusted. It is a platform design question: what should be composable, what should be standardized, who owns the rules, and how does the system evolve without breaking existing content?

A strong governance model does not remove editorial freedom. It defines the right kind of freedom.

### Why Gutenberg governance becomes necessary at enterprise scale

In a small WordPress implementation, editorial inconsistency may be annoying but manageable. In an enterprise platform, the same issue can become operationally expensive.

A loosely governed Gutenberg setup often creates problems such as:

*   brand inconsistency across landing pages, campaigns, and business units
*   overlapping custom blocks that solve nearly the same problem
*   patterns copied and modified outside their intended design rules
*   content layouts that depend on fragile nesting or undocumented editor behavior
*   publishing workflows that break when blocks are updated or removed
*   frontend teams carrying long-term maintenance for legacy editorial decisions

These are not just UX issues inside the editor. They affect delivery speed, QA effort, accessibility, design system adoption, and upgrade risk.

Enterprise teams usually need Gutenberg to support two goals at once:

1.  **Controlled flexibility for editors**
2.  **Predictable structure for the platform**

When governance is missing, organizations tend to overcorrect in one of two directions. They either allow too much freedom and get drift, or they lock everything down so tightly that editors work around the platform. Good governance sits between those extremes.

### The block surface area problem: custom blocks, core blocks, patterns, and exceptions

Gutenberg governance becomes harder as the available block surface area grows.

That surface area usually includes several layers:

*   **Core blocks** provided by WordPress
*   **Theme or platform-defined styles** applied to those blocks
*   **Custom blocks** built for specific content or business needs
*   **Patterns** that combine blocks into approved layouts
*   **Template structures** that constrain where blocks can be used
*   **Exceptions** introduced for campaigns, migrations, or local business requirements

The problem is not that any one of these exists. The problem is that many enterprise teams introduce them without defining how they relate.

For example, a content team may use a core Group block as a freeform layout tool, while engineering creates a custom Hero block, while design publishes pattern guidance in Figma, while another team adds a plugin that introduces overlapping container blocks. The result is not a block editor strategy. It is a stack of composition options with unclear precedence.

A healthier model is to define a hierarchy of preferred usage:

*   Use **core blocks** where they fit the design and content model cleanly.
*   Use **patterns** to package common page compositions.
*   Use **custom blocks** only when a repeatable content need cannot be reliably met with core blocks and patterns.
*   Use **exceptions** through a defined approval path, not as an informal practice.

This keeps the platform from becoming a collection of overlapping editorial choices that all produce different markup, styling, and maintenance responsibilities.

### Ownership model for design, engineering, and editorial operations

Governance fails when everyone influences Gutenberg but no one clearly owns it.

In enterprise environments, Gutenberg sits at the intersection of at least three functions:

*   **Design system ownership**: visual consistency, component rules, accessibility standards, content presentation intent
*   **Engineering ownership**: block implementation, rendering stability, performance, plugin architecture, testing, release management
*   **Editorial operations ownership**: authoring workflows, training, publishing needs, template usability, exception handling

The most effective model is shared governance with explicit decision rights.

A practical ownership structure often looks like this:

*   **Design** owns component intent, approved variants, and when a pattern should exist instead of a new block.
*   **Engineering** owns technical implementation, data structure, backward compatibility, block registration, and release safety.
*   **Editorial operations** owns authoring guidance, block usage conventions, content lifecycle needs, and feedback on workflow friction.
*   **Platform leadership** or a steering group arbitrates tradeoffs when brand consistency, delivery speed, and editorial flexibility conflict.

This ownership model should be documented in lightweight terms. Teams do not need a large committee for every change. They do need a clear path for questions like:

*   Who can approve a new block?
*   Who decides whether a pattern becomes a platform standard?
*   Who is accountable for deprecating a block?
*   Who reviews accessibility and design-system alignment?
*   Who communicates changes to editors?

Without those answers, Gutenberg governance becomes reactive. Decisions are made project by project, and the block inventory grows without discipline.

![](https://res.cloudinary.com/dywr7uhyq/image/upload/w_640,f_avif,q_auto:good/v1/cta--wphc--mid--architecture--compact)

### Clarify whether WordPress architecture still fits the platform.

Review whether ownership, extensibility, integrations, and operating constraints support future decisions.

*   Map decision risks
*   Surface ownership gaps
*   Clarify architecture priorities

[Run WordPress Health Check→](/wordpress-health-check?context=architecture#run)

### Block locking, allowed blocks, and template constraints

A governed editor does not depend on training alone. It uses platform-level constraints to make the preferred path the easiest path.

This is where [Gutenberg Block Editor Development](/services/gutenberg-block-editor-development) becomes practical rather than theoretical.

Three controls matter especially at enterprise scale:

#### 1\. Allowed block lists

Not every block should be available everywhere.

A broad block library may feel empowering, but it often increases inconsistency. Different content types usually need different authoring surfaces. A newsroom article, a product page, a campaign landing page, and a knowledge-base entry do not need the same composition model.

Restricting allowed blocks by template, post type, or context helps teams:

*   reduce clutter in the editor
*   prevent misuse of layout primitives
*   encourage semantically appropriate content structures
*   improve training and support

The goal is not minimalism for its own sake. It is to reduce unnecessary decision points.

#### 2\. Block locking

**Block locking in WordPress** is essential when a layout contains fixed structural elements that should not be casually moved or removed.

Locking is especially useful for:

*   required content regions in landing pages
*   legal or compliance-heavy sections
*   layout wrappers that control spacing or responsive behavior
*   pre-approved patterns that should allow text edits but not structural changes

Locking can preserve the integrity of a design system while still allowing editors to update content within safe boundaries.

The key is to apply it selectively. If everything is locked, editors will feel trapped. If nothing is locked, templates become suggestions instead of standards.

#### 3\. Template constraints

Template constraints define the editorial contract more clearly than style guides alone.

Instead of giving editors an empty canvas, enterprise teams often benefit from a structured starting point:

*   a page template with fixed regions
*   approved inner block sets within major content modules
*   prebuilt patterns for common content journeys
*   constrained areas for optional enhancement rather than full redesign

This shifts Gutenberg from a freeform page builder toward a governed composition system.

That distinction matters. Enterprise platforms usually need predictable outcomes more than limitless layout freedom.

### Versioning and deprecating blocks without breaking content

One of the most overlooked aspects of Gutenberg block governance is lifecycle management.

Blocks are not static assets. They evolve as the design system changes, accessibility standards improve, frontend implementations are modernized, and content requirements expand. Without a versioning and deprecation approach, old blocks can become permanent liabilities.

A practical block lifecycle policy should define:

*   how block changes are reviewed before release
*   which changes are non-breaking versus breaking
*   when a new variation should be introduced instead of changing existing behavior
*   how deprecated blocks continue to render safely in legacy content
*   when editors should be migrated to new patterns or replacements

In practice, teams should be careful about changing a block's markup, attributes, or expected nesting behavior in ways that can invalidate existing content. Even beneficial improvements can create risk if they assume all historical content follows current patterns.

Useful governance principles include:

*   Prefer additive changes over destructive ones.
*   Keep replacement paths explicit.
*   Maintain rendering support for legacy content long enough for a planned migration.
*   Document deprecated status clearly in editorial guidance and release notes.
*   Audit where blocks are used before removing support.

This is where Gutenberg intersects with standard enterprise release discipline. Blocks should be treated more like productized components than ad hoc editor features.

### How governance differs in single-site versus multisite WordPress estates

Governance requirements often change significantly between a single-site implementation and a multisite estate.

In a **single-site platform**, governance is usually about standardizing one editorial model across multiple teams. The main challenge is balancing local content needs with central design and engineering rules.

In a **multisite WordPress estate**, governance expands into controlled variation. Different sites may share a common design system and plugin architecture while still needing local flexibility based on audience, region, or business function.

That changes the governance questions.

Instead of asking only, "Which blocks are allowed?" teams also need to ask:

*   Which blocks are global standards across the estate?
*   Which patterns are site-specific variants of a common model?
*   Which exceptions are allowed only for certain sites?
*   How are shared blocks released without disrupting local editorial workflows?
*   How is block sprawl prevented when individual sites request custom solutions?

The answer is usually not to let every site manage its own block strategy independently. That creates exactly the fragmentation multisite is supposed to reduce.

A better approach is a layered model:

*   **Global platform blocks and patterns** for shared capability
*   **Site-level configuration or variation** where business differences are legitimate
*   **Governed exception intake** for needs that cannot be met within the standard platform

This preserves economies of scale while acknowledging that different sites may not need identical editorial experiences. Teams dealing with that complexity often need a clearer [WordPress Multisite Strategy](/services/wordpress-multisite-strategy) so governance rules, release patterns, and local variation stay aligned.

### Warning signs of block drift and recovery steps

Template drift rarely appears all at once. It accumulates.

Common warning signs include:

*   multiple blocks with similar visual outcomes but different implementations
*   patterns copied into custom content and edited beyond recognition
*   editors frequently asking which of several blocks they should use
*   frontend defects caused by unusual nesting combinations
*   high QA effort on content-heavy pages because layouts are unpredictable
*   requests for "just one more custom block" that duplicate existing capability
*   difficulty updating design tokens or styles because content uses too many structural variations

If these signs are already present, recovery should start with inventory and simplification rather than a full rebuild.

A useful recovery sequence is:

1.  **Audit the current block inventory**
    
    *   Identify core blocks in active use, custom blocks, patterns, and overlapping functionality.
2.  **Classify blocks by role**
    
    *   Separate foundational layout tools, editorial content blocks, campaign-specific blocks, and deprecated assets.
3.  **Define the approved path**
    
    *   Decide which blocks and patterns should be the default for major content scenarios.
4.  **Reduce available options**
    
    *   Remove or hide low-value duplication where possible.
5.  **Introduce stronger template and locking rules**
    
    *   Focus first on high-volume templates and high-risk content types.
6.  **Create migration guidance**
    
    *   Give editors and site teams a clear path away from deprecated structures.
7.  **Put release review in place**
    
    *   Require design, engineering, and editorial review before adding new block capabilities.

Recovery works best when it is framed as improving platform reliability, not as punishing editors for improvising within a weak system.

### A lightweight governance model teams can implement first

Not every organization needs an elaborate governance board to improve Gutenberg outcomes. Many teams can get immediate value from a lightweight operating model.

A good starting version includes five practices:

#### 1\. Maintain an approved block catalog

Document:

*   which blocks are approved
*   where they can be used
*   who owns them
*   whether they are standard, conditional, or deprecated

This alone reduces confusion and duplication.

#### 2\. Define when to use patterns versus custom blocks

A common rule is:

*   use a **pattern** when the need is primarily compositional
*   use a **custom block** when the need introduces reusable, distinct content structure or functionality

That prevents teams from creating new custom blocks for every layout request.

#### 3\. Limit block availability by context

Use allowed block rules and template design to shape the editing experience around real content models rather than generic flexibility.

#### 4\. Add lifecycle rules

Before a block is introduced, require answers to a few simple questions:

*   What problem does it solve?
*   Why are existing blocks or patterns insufficient?
*   Who owns it long term?
*   How will it be tested and supported?
*   What happens if it needs to be replaced later?

This small gate can prevent a lot of future platform debt.

#### 5\. Review governance through publishing outcomes

Do not evaluate Gutenberg governance only by how many blocks exist. Evaluate it by outcomes such as:

*   editor confidence
*   consistency across content types
*   reduced layout defects
*   easier design system updates
*   lower support burden on engineering

That keeps governance tied to platform performance, not bureaucracy.

Before the next WordPress decision

### Turn scattered platform concerns into a clearer risk baseline.

Run the WordPress Health Check to see where performance, plugins, infrastructure, content, analytics, security, and maintenance may need attention before deeper roadmap work.

[Run WordPress Health Check→](/wordpress-health-check?context=general#run)[Book a 30-min platform review→](https://calendar.app.google/HMKLsyWwmfU6foXZA)

No login required. Takes 5–7 minutes.

### Final thought

Enterprise Gutenberg success comes from recognizing that the editor is part of the platform architecture. It is not just a feature for authors, and it is not just a frontend concern for engineers.

When teams define ownership, reduce unnecessary block choice, use locking and templates deliberately, and manage block lifecycle with the same discipline they apply to other product components, Gutenberg becomes far more effective. Editors still get flexibility, but it is purposeful flexibility inside a system that can scale.

That is the real goal of **Gutenberg block governance**: not to restrict creativity, but to make consistency, maintainability, and quality the default outcome of editorial work.

Tags: Gutenberg block governance, WordPress, Enterprise WordPress, Editorial operations, Frontend engineering, Digital platforms

## Explore WordPress Governance and Platform Control

These articles extend the same enterprise governance lens into adjacent platform decisions. They cover how to control sprawl, manage multisite and shared platform structures, and align content platform choices with long-term operating discipline.

[

![WordPress Platform Governance: How to Control Plugin Sprawl at Scale](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260308-wordpress-platform-governance-how-to-control-plugin-sprawl-at-scale--cover?_a=BAVMn6ID0)

### WordPress Platform Governance: How to Control Plugin Sprawl at Scale

Mar 8, 2026

](/blog/20260308-wordpress-platform-governance-how-to-control-plugin-sprawl-at-scale)

[

![When WordPress Multisite Becomes a Platform Governance Problem](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20210420-when-wordpress-multisite-becomes-a-platform-governance-problem--cover?_a=BAVMn6ID0)

### When WordPress Multisite Becomes a Platform Governance Problem

Apr 20, 2021

](/blog/20210420-when-wordpress-multisite-becomes-a-platform-governance-problem)

[

![Drupal vs WordPress for Structured Content Platforms in 2026](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260327-drupal-vs-wordpress-for-structured-content-platforms-in-2026--cover?_a=BAVMn6ID0)

### Drupal vs WordPress for Structured Content Platforms in 2026

Mar 27, 2026

](/blog/20260327-drupal-vs-wordpress-for-structured-content-platforms-in-2026)

## Explore Gutenberg Governance and WordPress Architecture

These services extend block governance into the practical work of designing, implementing, and operating a more controlled WordPress platform. They are a strong next step for teams that want to reduce template drift, standardize content structures, and align editorial flexibility with long-term maintainability.

[

### WordPress Content Architecture

WordPress content architecture design for content models, taxonomies, and editorial structure

Learn More

](/services/wordpress-content-architecture)[

### WordPress Platform Strategy

WordPress platform strategy consulting: architecture principles, governance, and roadmap definition

Learn More

](/services/wordpress-platform-strategy)[

### Gutenberg Block Editor Development

Structured editorial interfaces for WordPress teams

Learn More

](/services/gutenberg-block-editor-development)[

### WordPress Plugin Architecture

Enterprise WordPress extensibility with controlled dependencies

Learn More

](/services/wordpress-plugin-architecture)

## Explore Governance in Enterprise CMS Delivery

These case studies show how governance, content structure, and reusable components were applied in real CMS delivery work. They help contextualize how editorial flexibility can be balanced with platform stability, design consistency, and safer long-term maintenance. Together, they extend the article’s guidance with examples from multisite, multilingual, and component-driven implementations.

\[01\]

### [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

\[02\]

### [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

\[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

![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