Where I can help
I work on projects that have outgrown standard configuration: they need a custom module, integration with another system or changes to application logic. My tools include PHP, JavaScript, Bitrix Framework D7, REST APIs, MySQL and Redis.
I also work on existing portals inherited from other teams. First, I investigate who uses the system, which changes already exist, what critical workflows depend on and how updates are released.
| Task | Starting point | Agreed outcome |
|---|---|---|
| Portal customisation | User scenario, permissions and existing implementation | A working scenario and checks of related features |
| Integration | Data ownership, exchange direction, errors and retries | An exchange contract, implementation and diagnostic methods |
| Module | Responsibility boundaries and platform extension points | An installable solution and documentation |
| Legacy development | Dependencies, problem areas and release procedure | A sequence of scoped changes |
Self-hosted and cloud editions
Self-hosted Bitrix24 runs on company infrastructure or with its hosting provider. Developers can work with server-side code and local modules. Cloud extensions use the available apps and REST APIs; an arbitrary PHP module cannot be deployed there.
This page focuses primarily on self-hosted development. Before estimating, I clarify the edition, module versions, infrastructure constraints and available integration options. The product name alone does not describe a project's technical conditions.
Relevant experience
In 2024, I developed a corporate portal on Bitrix24 Enterprise: recovering system context where documentation was insufficient, analysing dependencies and improving existing workflows.
In a partner B2B project, I helped clarify business requirements and redesign the architecture combining Bitrix24 with Site Management. The team implemented 1C exchange for the catalogue and partner discounts, as well as registration for Russian and international counterparties.
How I work
I begin by examining a specific scenario with its owner. Then I identify what the platform already provides, where custom development is needed and which constraints apply. The estimate is based on this scope.
I prefer extensions through local code and platform APIs. Placing a module in /local/ does not by itself guarantee compatibility with every update: dependencies and important scenarios still need checking against the version in use.
For integrations, I discuss retries, external-system outages and recovery in advance. For releases, I agree on checks, rollback and the information the maintaining developer needs.
What to share for an initial discussion
- Self-hosted or cloud, edition and known module versions.
- What the user does now and what needs to change.
- Which systems exchange data and who owns it.
- Infrastructure, deadline and release constraints.
A task description and an anonymised example are enough initially. Access details are discussed after the scope is defined. I work fully remotely and can take on a scoped engineering task or a role responsible for a technical function and team.