Enty: Architecture Transformation

I was originally brought onto the project as a Senior Developer to reinforce the team and ship features. However, after diving into the processes, I realized the main bottleneck wasn't a lack of manpower, but infrastructure "growing pains."

Processes that worked for a startup had begun to stall at the scale of thousands of clients. On my own initiative, alongside core product tasks, I developed and executed a technical modernization plan.

🛠 Processes & CI/CD

The team was wasting hours resolving merge conflicts, and QA testers often received the wrong builds. I took ownership of rebuilding the engineering culture:

• Implemented GitHub Flow: Standardized Git operations. This eliminated situations where untested code hit release after resolving conflicts (details below).
• Feature Preview Builds: Configured automated builds for every branch. QA can now test features in isolation without blocking other developers or waiting for a merge into an unstable shared branch.
• Documentation Culture: Introduced ADRs (Architecture Decision Records). Key technical decisions are now documented, discussed, and preserved in the project's history.

        gitGraph
    commit id: "Prod v1.0" tag: "v1.0"

    branch dev
    branch feature-1
    branch feature-2
    branch prerelease

    checkout dev
    commit id: "Junk Code"
    commit id: "Aband. Feature"

    checkout feature-1
    commit id: "Dev Work 1"

    checkout dev
    merge feature-1 id: "Merge to Test 1"

    checkout feature-2
    commit id: "Dev Work 2"

    checkout dev
    merge feature-2 id: "Merge to Test 2"

    checkout prerelease
    merge feature-1 id: "Release Feat 1"

    

Why the old flow failed

Beyond the need to merge code twice and resolve conflicts, there were critical issues:

• The Illusion of Testing: QA verifies Feature-1 on top of an "Abandoned Feature" commit. In the dev environment, everything works.

• Release Reality: Only Feature-1 makes it to prerelease. If Feature-1 implicitly depended on code existing only in dev (or conversely, had a conflict resolved only in dev), the production build would crash.

        gitGraph
   %% Основной ствол
   commit id: "Prod v1.0" tag: "v1.0"

   %% Инициализация веток
   branch prerelease
   branch feature-auth
   branch feature-ui

   %% Работа в Prerelease
   checkout prerelease
   commit id: "Sync Main"

   %% Работа в Feature-Auth
   checkout feature-auth
   commit id: "Dev Work"
   %% Квадратный узел на картинке часто обозначает type: REVERSE или HIGHLIGHT
   commit id: "Fixes after QA" type: REVERSE

   %% Слияние Auth -> Prerelease
   checkout prerelease
   merge feature-auth id: "Staging Deploy"

   %% Работа в Feature-UI (визуально происходит параллельно)
   checkout feature-ui
   commit id: "New UI"

   %% Слияние UI -> Prerelease
   checkout prerelease
   merge feature-ui id: "Staging UI"

   %% Финальный релиз в Main
   checkout main
   merge prerelease id: "v1.1" tag: "v1.1"

    

Key differences in the new process:

• Problem Isolation: If feature-ui is broken, it only breaks its specific Preview Build. Prerelease and Main remain clean. Developers do not block each other.

• What You See Is What You Get: The exact code (commit) approved in the feature branch and verified on prerelease is what lands in Main. No surprises during merges.

• Continuous Flow: We can release features one by one as soon as they are ready, without waiting for a "big release day" and untangling a chaotic shared dump.

🎨 Frontend Architecture

The project's UI kit consisted of unstable custom solutions where changing a single button could break a neighboring module.

• Migration to Shadcn-vue + Tailwind: Implemented a modern design system to replace maintenance-heavy custom components.
• Migration Strategy: Developed a plan for a smooth transition to update the interface in parts without halting product development.

📈 Business Results

These changes directly impacted Time-to-Market. The team stopped spending 20-30% of sprint time fighting conflicts and performing "manual" deployment steps. We reduced operational expenses (OpEx) on legacy support and redirected freed resources toward developing new features. The product became technically ready for further scaling without the risk of collapsing under its own weight.