Commerce Stack Operator Approach vs Agency
05.2026
AXON21 GmbH
634358f, Wien, Austria
AXON21 OÜ
16304707, Tallinn, Estonia
The Challenge
How can we maintain the highest level of existing projects maintenance while scaling to acquire new projects?
There is no straightforward solution for this challenge, as general and project-specific expertise cannot be easily scaled. And expertise is not just knowledge but, more importantly, the ability to take action, to perform necessary transformations of the project at deeper levels, which is inevitable for long-term project maintenance.
There are different solution providers, each dealing with these challenges and using different approaches — some more successful, some less. We observe several clear patterns among these approaches.
Agency Model
A standard solution for many Agencies is to transfer the most capable team (Team 1) to a newly acquired project (Project N+1) for the acquisition / implementation phase, while rotating existing projects (Project N, Project N-1, etc.) to second-tier teams (Team 2, Team 3, etc.).
Project-specific knowledge from Team 1 is initially transferred to Team 2 during the onboarding phase, then via a supervising engineer, and later only on a question-and-answer basis, while knowledge about Project N gradually evaporates from Team 1 members memory.
For Team 2, the new project becomes an overwhelming challenge not only because of its novelty and the lack of project-specific expertise at the beginning, but also because it exceeds their second-tier general expertise level. This becomes a great learning opportunity for the Agency team members (funded by the client), and in some cases, this challenge will be eventually overcome — the project maintenance quality may almost return to the initial level after a year or so.
For the client this period will also be challenging, but the outcome will be far less valuable: new functionality deployment will stall, and the overall quality of maintenance will decline — technical debt and vulnerabilities will accumulate. For months, and possibly for the entire project lifecycle, the main goal for the new team will be to grasp the entirety of the project, and any deep architectural tasks or necessary refactoring will be buried under the principle: if it works, don’t touch it.
Let’s be honest: all the onboarding procedures, any amount of documentation that is supposedly continuously created (or not), or self-explanatory and well-commented code will not prevent a decline in project maintenance quality during the transition from one team to another. And let’s be honest: any Agency will allocate its most capable team to the most challenging newly acquired project, where deadlines are tight, client relationships are fragile, and success is not guaranteed.
This is a matter of priorities, and this type of processes architecture leads to self-reinforcing Agency priorities — driving continuous new and new sales, maximizing profits during the acquisition / implementation phase by delivering «cutting-edge and future-proof» solutions, while being unable to sustain existing projects at a decent maintenance level.
This inevitably leads to the erosion of client retention over time and basically results in one of three main scenarios:
1. The project stagnates
It reaches a semi-stable state, which may appear to be a healthy agency—client partnership from a business perspective, but technically leads to gradual project decay until it is eventually decommissioned by the client as a failed proof of concept.
The client becomes convinced that eCommerce is just not for them (we are too small / too large, we have a «different» model, etc.), and the business is likely to be scaled back for years to come.
2. The project is transferred to an internal team.
This is presented as a completely natural and healthy process, but the underlying reason is simple — why pay agency-rates for second-tier expertise that can be replicated internally?
The client becomes convinced that an external technology partner is a one-off engagement, useful only for the implementation phase, and a significant portion of business-critical resources becomes permanently tied to building an internal capability that may never reach a top level of technological expertise and efficiency.
3. The project is transferred to another Agency.
Following a more or less disruptive breakdown with the current Agency, the project is handed over to a new Agency driven by its constant need for new sales. The project becomes a Project N+1, receives full attention and expertise from the new Agency’s Team 1, likely undergoes some form of replatforming, adopts all the «cutting-edge and future-proof» technologies — only to continue the same agency-model cycle as it progresses further.
The client gets an interesting story to tell about good and bad agencies, becomes more cautious in the future, and will most likely end up in scenario 2 in the next iteration.
Commerce Stack Operator Model
It is easy to say that we simply know better and will never fall into the «agency-model trap», but in reality, this model is quite sticky. It is counterintuitive to allocate projects in ways other than directly to teams. It is also counterintuitive not to fully deploy the most capable team to the most challenging and uncertain company project. What is the alternative?
We start with the same resources and limitations:
1. Existing Project N, which has recently passed the acquisition / implementation phase and is currently in the maintenance phase; the client is generally satisfied.
2. New Project N+1, ready for the acquisition / implementation phase; the client is waiting for results.
3. The most capable and only marginally scalable Team 1 with top-tier expertise.
4. A set of more scalable teams (Team 2, Team 3, etc.).
5. Any project «transfer» still degrades project maintenance quality, no matter how well the processes are designed.
To overcome the «transfer» bottleneck, we need to stop thinking about the project as a single monolithic system. We need to build a company level proprietary Stack Components Framework — a set of technical and operational solutions that can be implemented across multiple projects simultaneously and cover the majority of each of them. Each of the Components should be the best way to solve a particular task at this time, and should be constantly updated to the top level during the maintenance of existing projects and new projects acquisition / implementation.
If this vision is implemented from the outset across all projects, it unlocks a new level of direct and indirect synergistic effects, delivering significant value to both the company and all clients:
1. We can «slice» project-team allocation not by projects, but by team expertise, scalability, and Stack Component domain.
2. No loss of knowledge or focus — each team continuously improves its general and domain-specific expertise.
3. Each new project does not disrupt existing project processes, but instead «plugs in» to the existing Framework.
4. All existing projects benefit from one another and from each newly integrated project, as each receives updated Component versions.
5. The overall cost of maintaining the project portfolio is optimized, as each Component is reused multiple times.
6. The overall quality of project portfolio maintenance remains at a top-tier level.
A team composition architecture, which is itself an operational Component, is continuously evolving and consists of a Stack Architecture Team, responsible for evaluating, updating, and expanding the Stack Components portfolio, and several Project Teams, each responsible for project-specific last-mile delivery of Components and all project-specific functionality that is not recognized as Components.
While the Stack Architecture Team has a certain degree of project-specific knowledge across all projects, enabling it to identify opportunities for Component improvements and the creation of new Components, it is not fully engaged in day-to-day project routines and can observe a broad spectrum of projects simultaneously — detecting critical points where complex architectural decisions must be made, where clusters of Components require deep refactoring, or where Components become obsolete. The Stack Architecture Team is responsible for the company’s proprietary Stack, with a focus on its continuous improvement, while remaining closely connected to real-world implementation by actively participating across the implementation portfolio. It remains sharp and continuously develops its expertise.
Each Project Team receives ready-to-use Components from the Stack Architecture Team, along with overall architectural guidance. As the Stack Components Framework covers the majority of the project’s technical and operational structure, the Project Team is responsible for project-specific Component configuration and implementation, along with custom functionality that is not recognized as Stack Components by the Stack Architecture Team (frontend customization, integrations with internal systems, domain-specific modules, etc.).
Backed by the Stack Architecture Team and the Components Framework, the Project Team’s expertise increases naturally, as it observes complex architectural decisions without bearing the burden of making them. As Stack Components are unified across the project portfolio, a single Project Team can support one, two, or several projects, depending on the pace of delivering new functionality.
As a new Project N+1 emerges, the Stack Architecture Team follows a standard procedure:
1. Assess the required functionality.
2. Identify coverage within the existing Components portfolio.
3. Evaluate the required Component statuses — each Component should be brought to a top-tier, active state.
4. Evaluate functionality not covered by the existing Components portfolio — new Components may be identified for creation.
5. Jointly with the assigned Project Team, create an implementation schedule supported by operational Components.
6. The delivery process proceeds in parallel, with the Stack Architecture Team and the Project Team each delivering their respective parts in collaboration.