1C-Bitrix website for clinics.

Background

The “Dentika” clinic approached us to redesign and update its corporate website.
The project goals were clear and familiar:

• create a modern design,

• improve the structure,

• keep the CMS the client was used to, so the team’s workflows would not change.

The old site’s visual design already felt dated — that was the main motivation for the update.

The old “Dentika” website design on the UMI CMS:

At the outset the project looked like a standard redesign job, but in practice it turned out to be one of the most difficult we have had in recent years — above all because of communication and technical factors.

Mismatched expectations

At the preliminary estimate stage, the requirements were not fully clarified.

• We were planning development on the 1C-Bitrix CMS;

• The client expected to keep working with UMI, as before.

This point was not explicitly recorded at the start. As a result, the budget and timeline had already been agreed when the disagreement over the platform came to light.

After discussion, we decided to work on UMI in order to preserve the client’s familiar processes, despite the limitations of that CMS.

Getting started: page-by-page design approval

Work began with creating and approving pages one stage at a time:

1. Home

2. Contacts

3. Special offers

4. Prices

These were to be followed by the About, Doctors, Portfolio, Blog and other sections.

The client insisted on page-by-page approval — each page was discussed separately and went through several rounds of revisions.

At this stage we found that visual and UX decisions had to be reworked to suit personal taste, and design recommendations were rarely accepted.

Although the mock-ups appeared to be approved, the client often came back with further comments after the design had been signed off. Most of the revisions concerned interface details — spacing between blocks, button placement, minor visual accents. These changes are not always noticeable visually, but implementing them took time and rework at both the design and the front-end stages.

Attempting to roll out the first pages

Once four pages were ready, the client insisted on deploying them directly into the existing site. In other words, the site was to be partly old and partly new.

We strongly objected, explaining that:

• the design and structure would look inconsistent;

• there could be problems with navigation and page transitions;

• technically, UMI is not designed for “stitching” new modules on top of an old version;

• conflicts were likely in styles, scripts, and the logic of forms and modules.

But the client was adamant:

“The site has to start looking new right now. We don’t care what is more convenient for you — we need a visible result.” We accommodated the request and tried to implement this scheme. However, it led to major technical failures.

Diagnostics and technical collapse

The attempt to embed four new pages into the client’s existing site was unsuccessful. After the initial integration it became obvious that the site was “breaking” in unexpected places. We decided to run diagnostics on the UMI system.

The diagnostics showed:

• The client’s site had been built on a 2018 version of UMI that had never been updated.

• In the course of integrating the new pages, the CMS had to be forcibly updated to the 2024 version.

• As a result:
  
  

• the admin panel login stopped working,

• the built-in mail broke,

• some of the activity pages disappeared,

• the interface became unstable.

Even UMI’s technical support could not guarantee a recovery, since migrating between such distant versions is not officially supported.

The limit of compromise: abandoning the hybrid approach entirely

Once the diagnostic results were in, it was clear that continuing in the current format made no sense. Attempts to “glue” new pages onto the old core were not just a hindrance — they could lead to the loss of all data and a complete site failure.

After a meeting with the client, we proposed the only reliable and scalable option:

• Build the new site in full, from the first page to the last,

• Test it on a staging domain,

• After final approval, move it entirely to the main domain,

• Replace the licence key and launch a stable version from scratch.

We explained to the client openly:

“Trying to combine the old core with a new design is a road to nowhere. We will keep spending time, effort and money without getting any closer to the final result. For you to get a stable, modern, working website, we have to see this through to the end.”

The client agreed.

Conclusions and insights at this stage:

• Never start an estimate without examining the current state of the site, especially if the project involves a redesign or migration.

• The CMS is a critical input and must be recorded in writing at the briefing stage.

• Hybrid solutions = double the work, especially when dealing with systems on outdated versions.

• Page-by-page approval should be limited to a set number of rounds and include UX/design reasoning.

Stage: children’s pages and the widening scope of revisions

After the full-migration strategy was approved and the hybrid approach abandoned, we continued developing the remaining sections of the site. The next stage was the children’s dentistry area, which had originally been designed as a single standalone page.

Initially the client provided a colour palette and style for the “Children’s Dentistry” section. The designer put together a mock-up, the client approved the direction, and the work moved into finalisation.

However, a few days after approval the client came back with a request:

“We’ve changed our minds. We want a different look — let’s redo it in a different colour scheme.”

We explained that changing the approved palette at this stage would mean:

• extra time to rework the design,

• revisiting elements that had already been created,

• a delay to the front-end build.

Nevertheless, at the client’s request, the work was redone. The second iteration was accepted, but time had been lost.

Palette no. 1:

Palette no. 2:

Services: requirements fragmenting along the way

The next block was the service pages, covering both adult and children’s dentistry. The original specification called for a single visual style shared across the whole site, plus one general page dedicated to children’s dentistry.

However, while we were already working on the service cards, the client changed the concept again:

• Within the children’s section, several separate services now had to be developed, each in a “children’s” style.

• The overall idea of the redesign was effectively changed: instead of one children’s block, an entire mini-system within the site.

These changes were not recorded in the original specification. Nevertheless, the team accommodated the client and included the new pages in the work plan at an additional cost, taking into account the need to preserve visual consistency and navigation logic.

Static pages: the developer’s decision

When we reached the development of the children’s pages (with a separate design that differed from the “adult” part of the site), the developer ran into a technical limitation:

In the current 1C-Bitrix architecture, it was impossible to integrate the children’s pages into the site admin panel while preserving their unique design and structure without completely reworking the CMS templates and logic.

Why the integration did not work

• The children’s pages required a separate set of styles, HTML structure and markup that did not fit into the current 1C-Bitrix template.

• The system had been built around a single global template for all pages.

• To embed the children’s pages in the admin panel, we would have had to:
  
  

• write separate component templates;

• create new wrapper pages;

• rewrite part of the core/modules.

This would not only have taken a great deal of time but also risked damaging the site’s existing logic. To keep to the deadlines and maintain a stable implementation, the developer made a technical decision:

• The children’s service pages were built as static blocks (rather than as cards/dynamic entities).

• This made it possible to code and deploy them quickly without touching the CMS architecture any more than necessary.

We made it clear to the client that the current implementation was a quick solution to a visual problem, but with limited flexibility.

Stage summary

• Work on the children’s section took 3 times longer than planned.

• Changes made along the way went beyond the original agreements but were not formalised in supplementary agreements.

• The team kept up the pace and maintained quality and style, despite frequent changes to the brief and the visual decisions.

• Decisions were made on the fine line between flexibility and keeping the project manageable.

Design and front-end for adult services

After completing the home page and several key pages, the team moved on to developing the service pages for the clinic’s “adult” audience.

Initially the concept was simple:

• use the approved “adult” visual style (colour palette, typography, interface elements)

• provide a single template for all services to speed up development and simplify populating the site later.

Implementing the shared visual style

We prepared a design that:

• matched the home page in colour and structure;

• had blocks with the service description, photos, price and a booking form;

• was responsive on all devices;

• could easily be scaled for future services.

First iteration of an adult sub-service:

The approved mock-up:

At this stage the team expected a quick sign-off: the design was logically structured, matched the specification and kept a consistent style.

Approval and revision problems

However, the process followed an already familiar scenario:

1. Multiple rounds of revisions
   After every approval, new adjustments appeared — from swapping photos to rearranging blocks.

2. Going back on decisions already approved
   Some revisions contradicted previously approved mock-ups.

3. Aesthetic tweaks “by eye”
   The changes were often unrelated to improving UX or branding and instead reflected the client’s subjective wishes (“a slightly lighter background”, “move the button”, “add more white space”).

How this affected the timeline

• What was planned as a quick design and build of the adult services turned into a lengthy approval cycle.

• Because revisions came in at the front-end stage, we had to go back to the mock-ups, which increased the effort 2–3 times over.

• Constantly returning to earlier stages threw the team off plan and pushed back development of the next pages.

Outcome:
Although the adult services visuals were ultimately implemented and matched the overall concept of the site, the constant revisions and re-approvals made this stage one of the most labour-intensive in the project.

1C-Bitrix CMS: what was delivered as planned

1. Core site architecture

• A single responsive template was created for the “adult” part of the site, integrated with the admin panel.

• Menus, breadcrumbs and cross-linking between sections were implemented and work correctly.

2. Dynamic sections

• “Special offers” section — managed through the admin panel, with the ability to add, edit and archive offers.

Screenshot — editing a Special offer item in the Special offers section:

• “Prices” section — with a flexible price-list structure that can be updated without a developer’s help.

• Blog / News — with categories, publication dates and sorting.

Screenshot — editing an article in the Blog section:

• Doctors — individual cards with photos, job titles, experience and specialisation.

Screenshot — editing a Doctor item in the Doctors section:

• Portfolio — the ability to upload and organise examples of work.

3. Forms and feedback functionality

• An appointment booking module linked to a specific service or doctor.

• A contact form with spam protection.

• Forms integrated with e-mail notifications.

4. Technical optimisation

• 1C-Bitrix caching configured to speed up page loading.

• Analytics counters connected (Yandex Metrica, Google Analytics).

• Human-readable URLs configured.

Implementing the “Happy Hours” block

One of the key additional tasks in the project was developing the “Happy Hours” feature — an interactive block that lets patients book free time slots at a discount.

To ensure flexibility and avoid burdening the site’s main structure, a separate module was built with its own database and admin panel. 

The “Happy Hours” admin panel:

The user-facing view:

This made it possible to:

• manage free slots independently of the site’s main content;

• set the date and time;

• choose the doctor seeing patients in that slot;

• tie an offer to a specific branch.

• quickly add and change offers;

• collect statistics on how patients respond to discount windows.

As a result, the clinic gained a convenient tool for filling up doctors’ schedules and encouraging patients to come in during quieter hours.

Here is a version of the text for the “Conclusions and lessons from the project” block that carefully sums up the results, shows the lessons and gives recommendations without casting the company in too negative a light:

Conclusions and lessons from the project

The project showed how important it is to record all technical and organisational conditions in advance, in order to minimise the risk of changes and rework during the project.

What could have been done better

• Clarify all key technical points at the estimate stage, including the choice of CMS and platform limitations;

• Introduce formal rules for handling revisions — which changes go into the design and which are made only at the content-management stage;

• Involve technical specialists more closely at the design approval stage, so the implementation complexity of individual blocks is assessed straight away.

How to avoid similar situations in future

• Clearly record the requirements and the agreed CMS in the documentation right at the start;

• Use stage-by-stage mock-up approval with a cap on the number of revisions after sign-off;

• Use separate test environments for complex functional blocks (such as “Happy Hours”) to minimise the risk of conflicts with the main system.

This approach maintains quality, avoids unforeseen delays and increases the client’s trust in the team.