CelinQ Insights · No. 28

Scaling an architecture practice from one person to a team

The tooling shift that lets a solo practice become a group without chaos.

Almost every architecture practice begins as one person and a repository. A single architect opens the model in the morning, works through the day, saves in the evening, and the whole of the organisation's structural knowledge sits inside one file that one person understands completely. This is a remarkably productive arrangement while it lasts. There is no coordination overhead, no ambiguity about who owns what, no waiting for anyone else. The architect holds the entire shape of the model in their head, knows why every element is named the way it is, remembers which decisions were provisional and which were load-bearing, and can move through the repository at the speed of thought. For a surprising length of time, this is not a limitation. It is a superpower.

The trouble is that success punishes it. The practice that does good work gets asked to do more work. A second architect is hired, or a contractor is brought in for a project, or a client's own staff want to contribute to the model they are paying for. And at precisely the moment the practice most needs to grow, the arrangement that made it productive turns into the thing holding it back. The single file that one person understood completely is now something two or three people need to touch, and the mechanisms that were invisible when there was one contributor become painfully visible when there are several. The transition from one to a team is where a great many architecture practices quietly stall, not because the people are wrong or the ambition is misplaced, but because the tooling was never designed for the moment the practice succeeded.

What actually breaks when the second person arrives

The first thing to understand is that the problem is not really about the software refusing to let two people work. It is about what the shared model becomes when more than one person depends on it. In the solo arrangement, the repository is a private workspace. It can be messy, half-finished, full of experiments and abandoned branches of thought, because only one person ever sees it and that person carries the context. The moment a second architect arrives, the repository stops being a private workspace and becomes a shared surface. Every save one person makes is now something the other has to reckon with. Every naming choice, every restructured package, every deleted element is now a message sent to a colleague who was not in the architect's head when the choice was made.

The common ways of coping with this are all bad, and they are bad in instructive ways. The most primitive is the shared drive, where the repository file sits in a folder that both architects can reach. This works until the exact moment it matters, which is the moment both architects have the model open at once. Then the tool's file locking asserts itself, one of them is told the repository is in use, and the practice has just discovered that its collaboration model is a queue. Two architects, one turn each, taking it in turns to hold the only copy that counts. This is not collaboration; it is a relay race with a single baton, and it gets slower as the team gets larger, which is precisely the wrong direction.

The second coping mechanism is worse because it looks better. The team decides to divide the model into separate files, one per architect or one per domain, on the theory that if everyone owns a different file nobody will collide. For a while this feels like progress. But an architecture model is not a set of independent documents; it is a web of relationships. The application in one person's file depends on the technology in another person's file, which realises a business capability described in a third. Splitting the file does not split the dependencies; it only hides them, and it converts every cross-cutting question into a manual reconciliation exercise. Eventually someone has to stitch the fragments back together to produce a coherent view, and that person becomes a bottleneck of a new and more miserable kind, spending their days as a human merge tool instead of an architect.

The passage from one architect to a team is rarely blocked by a lack of talent or ambition. It is blocked by the discovery that the model, which felt like a shared asset, was actually a single-occupancy dwelling.

The third coping mechanism is the discipline of taking turns by agreement rather than by file lock. The team agrees, verbally or by calendar, who has the model this week. This is the approach of serious, conscientious people trying to make a bad situation work through professionalism, and it is heartbreaking to watch because the professionalism is real and the situation defeats it anyway. Human scheduling does not scale past a very small number of people and it collapses entirely the moment the work is genuinely parallel, which is exactly when a growing practice needs parallel work most. The architect who has an idea on Tuesday but does not have the model until Friday will either lose the idea or work around the process, and both outcomes erode the very thing the discipline was meant to protect.

The hidden cost is not collisions, it is caution

Beneath the visible failures there is a subtler and more expensive one. When a repository is shared badly, people become cautious in ways they cannot quite articulate. An architect who knows that a large restructuring will collide with a colleague, or will lock everyone else out for a day, or will be impossible to reconcile cleanly, simply stops proposing large restructurings. The model ossifies not because it is correct but because changing it has become socially and mechanically expensive. Elements that should be renamed keep their bad names. Packages that should be reorganised stay tangled. The model drifts steadily away from the reality it is supposed to describe, because every improvement now carries a coordination tax that nobody wants to pay.

This is the true cost of poor multi-person tooling, and it almost never appears on any budget line. It shows up as a model that is a little more out of date every quarter, as architects who quietly maintain private notes because they do not trust the shared repository to hold their thinking safely, as a growing gap between the diagram everyone points at in meetings and the truth everyone knows in private. A practice that cannot change its model cheaply cannot keep its model true, and a model that is not true is worse than no model, because it lends false confidence to decisions. The caution is invisible, it is corrosive, and it is a direct consequence of asking one-person tooling to carry a team.

Local-first changes the unit of collaboration

The way out is not a bigger central server or a stricter locking policy. It is a change in what each person is actually working against. CelinQ is built local-first, and in the context of a growing practice that phrase has a very specific meaning. Each architect edits their own local repository, a real and complete copy of the model that lives on their own machine and that they can work in at full speed whether the network is present or not. Nobody is reaching across a wire into a single shared file that only one person can hold at a time. Everyone has their own copy, and the copy is not a stale export or a read-only snapshot; it is a fully working repository they can edit freely.

Collaboration then happens through a background companion that reconciles each person's saves with a shared workspace running on a server the organisation runs itself. The distinction matters enormously for a scaling practice. In the old shared-file model, the unit of collaboration was the file, and there was only one of it, so collaboration was inherently a contest for possession. In the local-first model, the unit of collaboration is the change, and changes flow continuously from each person's local repository into the shared workspace and back out to their colleagues. Two architects working on different parts of the model at the same time are no longer competing for a baton. They are each working freely, and their work is being woven together in the background as they go.

This is the difference between a queue and a team. When the second architect arrives, they do not join a rota for access to the one true file. They clone the shared workspace to a fresh local repository of their own and start working immediately, at full speed, with the whole model available to them. When a third and fourth arrive, the same thing happens, and nothing about the arrangement degrades as the numbers grow. The practice can scale because the mechanism of collaboration does not have a single point through which everyone must take turns. There is a shared workspace, and it is real and it is central, but reaching it is not a lock; it is a reconciliation.

Merging is the part everyone underestimates

The natural objection at this point is the one every experienced architect will already be forming. If everyone has their own copy and everyone edits freely, what happens when two people change the same thing? This is the question on which the entire promise stands or falls, because a system that lets everyone work freely and then loses half their work at reconciliation time is worse than the queue it replaced. The answer is the part of collaborative modelling that people consistently underestimate until it has burned them, and it is where CelinQ concentrates its most careful engineering.

The merge engine, CelinQ Fusion, performs a deterministic, reproducible three-way merge at the granularity of individual model facts. The phrasing is precise and worth unpacking. Three-way means the merge does not simply compare two versions and guess; it looks at both changed versions and the common ancestor they diverged from, which is what allows it to tell the difference between a change one person made and a change the other person made, rather than treating the whole model as an opaque blob. Model-fact granularity means the reconciliation happens at the level of individual properties and relationships, not whole diagrams or whole files, so two architects editing different attributes of the same element, or different elements in the same package, simply both succeed. Their changes do not collide because, examined closely, they were never actually in conflict.

Deterministic and reproducible mean that the same set of changes always reconciles to the same result, every time, on every machine, which is what makes the behaviour trustworthy rather than merely usually correct. A merge that produced different outcomes depending on timing or order would be impossible to reason about and impossible to defend, and a practice that could not trust its reconciliation would quickly retreat to taking turns again. When two changes genuinely do conflict, because two people really did change the same fact in incompatible ways, Fusion does not silently pick one and throw the other away. It isolates the conflict explicitly and surfaces it for a person to resolve, and it does so without discarding anyone's work in the process. Deletions are handled with tombstones rather than by simply making an element vanish, so that a deletion is itself a recorded fact that can be reconciled properly rather than a hole that reappears mysteriously the next time someone syncs.

The reason this matters so much for a scaling practice is psychological as much as technical. The caution described earlier, the quiet refusal to make large changes because they will be painful to reconcile, dissolves only when architects genuinely trust that the tool will not lose their work and will not silently lose anyone else's. Trust of that kind cannot be asserted in a brochure; it is earned save by save, as people watch parallel work weave together cleanly and watch the rare genuine conflict be surfaced honestly rather than buried. Once a team trusts the merge, they start making the large changes again. The model becomes malleable, and a malleable model can stay true.

Roles, review, and the shape of a real practice

A team is not only a collection of editors. As a practice grows, the people around the model stop being interchangeable. There is usually someone who owns the standard and answers for the model's integrity, there are architects doing the substantive work, there are contributors from the client or from other teams whose changes should be welcomed but reviewed, and there are stakeholders who need to see the model without any ability to change it. A tool that treats everyone identically forces the practice to enforce these distinctions by convention and goodwill, which is to say it does not enforce them at all.

CelinQ carries a set of roles that map onto how practices actually organise themselves. A Viewer can see the model but not change it, which is exactly what a stakeholder or an auditor needs and no more than they should have. An Editor does the substantive modelling. An Administrator manages the workspace and the people in it. An Owner holds ultimate control. These are not decorations; they are the difference between a practice that can safely widen its circle of contributors and one that can only grow by adding people it trusts absolutely with everything. When a client's own staff want to participate in the model, or when a junior architect joins, the practice can include them as Editors or Viewers without handing over the keys to the whole arrangement, and it can do so knowing that the boundary is enforced by the tool rather than by everyone remembering to be careful.

Alongside roles sits change review and governance, and this is where a growing practice starts to feel less like a group of individuals and more like a discipline. Changes flowing into the shared workspace can be reviewed rather than simply accepted, which gives the person who owns the model's integrity a place to stand. A complete, ordered revision history means that every change is recorded in sequence and nothing arrives from nowhere. When a new contributor makes a change that does not fit the standard, it is visible, attributable and reversible, rather than being an anonymous mutation discovered three weeks later when someone wonders why a diagram stopped making sense. Growth without governance is how a clean model becomes a mess; the history and the review are what let a practice grow and stay coherent at the same time.

Lightweight presence rounds this out in a quiet but genuinely useful way. When several people are working against the same shared workspace, a small awareness of who else is active turns the practice from a set of people editing in isolation into a group that has some sense of each other. It is deliberately lightweight, because heavy presence machinery becomes surveillance and nobody models well while feeling watched, but a little awareness goes a long way toward making a distributed team feel like a team rather than a set of strangers touching the same file.

Growth without a central bottleneck

Step back and consider what has actually changed about the shape of the practice. In the one-person arrangement, the architect was the model and the model was the architect, and that identity was both the strength and the ceiling. In the badly-shared arrangement, the practice bought more people but kept a single point of contention, so adding people made things slower and more fragile rather than faster and more robust. The local-first arrangement removes the central point of contention without removing the central point of truth. There is still a shared workspace that holds the authoritative model, and it still runs on infrastructure the organisation controls, so nothing about sovereignty or governance is surrendered in the name of scale. But the daily work no longer passes through a single lock, so the practice can add its second, third and fifth architect without the coordination cost climbing to meet them.

There is a further benefit that reveals itself only over time. Because a workspace can be cloned to a fresh local repository, onboarding a new architect stops being a ceremony and becomes a routine. The new person clones the workspace, and they have the entire model and its complete history on their own machine, ready to work in at full speed. They are not handed a stale export and told to be careful. They are not waiting for their turn with the file. They are a full participant from the first save, and because the history lives in the shared workspace on the organisation's own server, the practice's memory does not depend on any one person's laptop surviving. The knowledge that used to live in one architect's head now lives in a place the whole team can reach and the organisation genuinely owns.

None of this makes growing a practice effortless, and it would be dishonest to pretend otherwise. Adding people still means agreeing on standards, still means reviewing work, still means the harder human labour of building a shared way of thinking about the architecture. What changes is that the tooling stops fighting the growth. The mechanical friction that used to turn every new hire into a coordination problem is largely removed, which frees the practice to spend its energy on the parts of scaling that actually deserve it: the judgement, the standards, the shared craft. Smart Sync, which quietly adapts how often the companion reconciles rather than hammering the network on a fixed schedule, means that this continuous collaboration does not come at the cost of a machine that is always straining. The synchronisation fades into the background, which is exactly where it belongs.

The honest summary is this. A solo practice runs on the fact that one person holds everything, and that is a genuine strength right up until it becomes the ceiling. The move to a team is not really a hiring decision; it is a decision about whether the model can be shared without becoming a battleground. Tooling that treats the repository as a single-occupancy file will make that move painful no matter how good the people are, because it forces a team to fight over a resource that was only ever built for one. Local-first collaboration, with a real merge engine underneath it and real roles and history around it, changes the resource itself, so that the practice grows into a larger version of what it already was rather than mutating into something slower and more fragile. That is the difference between a practice that scales and one that merely gets busier, and it is decided, more than anyone likes to admit, by the shape of the tool.