Why I split our platform into repositories, and merged it back in one day

Most architecture decisions are written up when they work. This one I’m writing up because I reversed it. In March 2026 I split the Ta’az platform into one repository per part. In June I put it all back together, in one day, without losing a commit. Both decisions were right at the time they were made, and the interesting part is how I knew when to switch.

The problem

The Ta’az Digital Platform is the in-house platform of Ta’az, the IDF Civilian Employees Employment Center: a Hebrew portal, the content-management system behind it, a secure file and media service, a notification service and a search engine, all on one shared design system and one sign-in. It gives HR staff, commanders and employees one self-service place for official information, on a closed network with no internet. I wrote its brief in October 2025, and for its first five months it lived in one repository.

That repository grew fast. By January 2026 the shared component library had already been split inside it into core, interface, layout and utility packages, plus calendar, editor and file-explorer features. By February it also held the file and media service with its own admin app, single sign-on and a reworked search.

Then two things changed in March:

• A second developer joined. Mazal Avitbul came on to build the notification service. Until then I had been the project’s only developer.
• The parts had started to move at different speeds. The portal changed weekly. The shared packages needed to change carefully, because everything used them. The file and media service had its own Python dependencies.

What I tried: one repository per part

In March 2026 I split the code into one repository per part: the shared packages, the portal, the file and media service, the sign-in, and then the notification service, tied together by a hub repository. The goals were written in the split plan:

• each part gets its own release cycle and its own isolated Python environment;
• the shared packages are upgraded by version, so a part can move to a new version when it is ready;
• a second developer can work in one repository at a time, without stepping on everything else.

Each repository also got a CONTEXT.md, a short document that an AI agent reads before it touches that part.

In the same plan I also wrote down the price, before I paid it: a change that crosses parts needs several pull requests. I knew that was the weak point. I accepted it because, at that moment, parallel work mattered more.

And the split did its job. Mazal built the notification service, about 4,000 lines, and a Docker setup for local development, on the shared service structure I set. Five of her six pull requests were merged after my review; the sixth was closed when her service moved to its own repository. March was the platform’s second-busiest month, with 76 commits.

The price came due

In May 2026 I reworked the shared library. In one repository it would have been one change. Across repositories it was a wave: five coordinated pull requests that could only be merged together.

It still went wrong. One merge had to be reverted and its conflicts fixed by hand. The coordination itself had become a large part of the work: the order of the merges needed as much care as the change.

The split had also made me the platform’s gatekeeper. Across the split repositories, 20 of the 22 pull requests were merged, all of them by me after review. That was healthy for quality, and it meant every cross-part change queued behind one person reading five repositories in the right order.

That was the signal. Not a vague feeling that “monorepos are better”, but the exact cost my plan had predicted, now measured in pull requests and in a revert.

What worked: one workspace, full history

In June 2026 I brought the parts back into one pnpm workspace, in a single day, with every commit of their history. The shared packages, the portal, the file and media service and the notification service each came in through git subtree add, as a merge into a folder of its own, so nothing was squashed and nothing was lost; I retired the sign-in repository that day, because sign-in moved to an external single-sign-on service.

The workspace keeps the boundaries the split had given me, as packages instead of repositories:

taaz workspace
├── packages   @taaz/ui · core · layout · utils
│              calendar · editor · explorer · showcase
├── apps       portal · file and media service
└── services   notifications · search

Eight shared packages, two apps, two services. A change that crosses parts is now one commit and one review again, and the shared packages are still separate, each with its own name and its own place.

The merge also turned out to suit what came next. From June I worked with Claude Code, from written specs, plans and tests, and an agent that can see every package at once can make a cross-cutting change in one coherent commit. June was the platform’s busiest month by far, with 196 commits. Of the 217 commits from June on, 179 were made with Claude Code under my direction. The move to external sign-in and the publisher workflow, which arrived inside the file explorer the same month, each touched several parts at once.

The workspace made later clean-ups cheap, too. In July I moved the platform’s deployment code into Launchpad, my deployment tool, and the platform deleted 3,186 lines of its own deployment engine. In August a management request, hiding chosen holidays from the calendar, went from a written spec at 09:18 to a finished feature at 16:57, across the API, the CMS screen and the public calendar: ten commits in one working day.

What I would do differently

I would still split the work for a second developer. I would not necessarily split the repository to do it. Most of what I wanted in March – a release rhythm per part, versioned shared packages, and a teammate with her own area – a workspace with clear package boundaries also gives. I chose the stronger separation before I had tried the lighter one.

I would also write an exit condition into the plan, not only the price. My March plan said what the split would cost. It didn’t say when the cost would be too high. In May I recognised it, but a sentence like “if a shared change needs more than two coordinated pull requests, we merge back” would have made the decision faster and less personal.

And I’m glad of one thing I did do: writing the price down before paying it. When May came, I wasn’t arguing with myself about whether the split had been a mistake. I was checking a prediction.

Where it lives

The platform is in production on Ta’az’s closed network, built for 14,500+ users. It is my flagship project, and the Ta’az Digital Platform case study covers the whole system: the portal, the CMS, the file and media service, the design system and the three generations of its architecture. Mazal Avitbul built the notification service and the local development setup; everything else in this post was my call.