A surprising number of Adobe Commerce engagements are running on less labor than the customer thinks. The agency sold you a “team of six.” The proposal listed senior developers, mid-level developers, a project manager, a QA engineer, and a tech lead. Six months in, you look at your commit history and you can count two recurring author names. That is a capacity problem, and it explains why velocity feels lower than the staffing plan suggests.
This is not always malice. Agencies share staff across accounts as a matter of business necessity. The question is whether the sharing is honest and the capacity is right-sized for the work. Most relationships break down not because the agency is bad, but because the staffing model in the proposal was aspirational and nobody renegotiated when reality showed up.
Bemeir works with in-house engineering leaders who want to bring discipline to this conversation. The framework below is the one we recommend. It does not require trust. It requires evidence and a regular cadence for talking about what the evidence shows.
What “capacity” actually means on a Magento project
Capacity has three components, and most teams conflate them. The first is named heads, which is the list of specific people assigned to your account. The second is allocated hours, which is the number of hours each named head is supposed to spend on your work in a given period. The third is realized output, which is the number of meaningful commits, completed tickets, or shipped features actually delivered.
Healthy agency engagements have all three numbers in alignment. Unhealthy ones have a beautiful named-heads list, a soft allocated-hours number, and a realized-output number that does not match either. You want to know the realized output number, and you want to know it in a format that updates weekly without having to ask.
A useful frame: the three numbers should never diverge by more than 20 percent in either direction. If they do, you have a capacity conversation to have. If the agency cannot tell you what their realized output looks like by named head, that itself is a capacity finding. The Atlassian guide to engineering velocity is a reasonable shared vocabulary for these conversations even though it is Jira-flavored.
How to read your commit history honestly
Your git history is the most honest source of capacity data on the project, and you almost certainly are not reading it carefully. Pull the last 90 days of commits across all relevant repositories and answer six questions. Who are the unique authors? How many commits did each one make? What is the median commit size by author in lines of code changed? How many of those commits touched core business logic versus configuration versus documentation? Who reviews each author’s pull requests? Which authors have not touched the codebase in the last 30 days?
The answers will surprise you. We have walked into engagements where the named team had eight developers on the staffing chart and the actual git history showed three authors, with one of them responsible for 70 percent of business-logic changes. That is a single point of failure on a project the founder thought was diversified across a full team. It is not necessarily a problem, but it is information the agency owed the customer.
Bemeir’s internal practice is to share commit-author summaries with clients on a monthly basis as part of the standard project review. It is not standard across the industry, and not enough customers ask for it. The asking is what makes the asking work, because once you ask, the agency adapts to the visibility.
The staffing model questions that get honest answers
Once you have a commit-history baseline, you can ask the agency staffing questions and check the answers against evidence rather than against marketing.
The questions to ask, in order, are these.
- Who are the named developers currently on our account and what is each one’s allocation in hours per week?
- Of those allocations, what percentage is reserved versus shared with other accounts?
- Which of those developers has not committed to our repository in the last 30 days, and why?
- What is the team’s plan if our lead developer is on PTO for two weeks?
- Which of these developers does the bus-factor analysis say we cannot lose without significant risk?
- What is the onboarding time for a new developer to ramp on our codebase, and what would trigger that ramp?
These questions force the agency to talk about reality rather than aspiration. They also give the agency a chance to bring you up to speed on capacity issues you may not have seen, which is healthy. The agencies that take these questions well treat them as good project hygiene. The ones who get defensive are usually defending something. Both responses are useful data.
A capacity scorecard you can run monthly
The table below is the scorecard we recommend clients run as part of their monthly project review. It takes about 45 minutes to compile if the data is clean. The point is to have the same conversation every month, with the same numbers, so you can see trend rather than snapshot.
| Metric | This month | 3-month trailing avg | Notes |
|---|---|---|---|
| Unique commit authors on our repos | |||
| Total commits | |||
| Median commit size (lines changed) | |||
| Tickets closed | |||
| Pull requests merged | |||
| Production deploys | |||
| Incidents in production | |||
| Average ticket cycle time (days) |
The composite picture of these metrics will tell you whether the agency is delivering at the rate the contract assumes. If unique authors trend down while ticket cycle time trends up, you are losing capacity even if the proposal still says you have a “team of six.” That is the moment to renegotiate either the scope or the staffing, not three months later when the launch slips.
The GitHub engineering metrics overview and the DORA metrics framework are two reference points worth having on hand when you set thresholds on these numbers. They are not Magento-specific but they translate cleanly.
When to escalate the capacity conversation
There are four triggers that should prompt a structured capacity conversation rather than a passive monthly review. The first is a meaningful and unexplained drop in unique commit authors. Two months in a row of dropping author count is not a coincidence. The second is a sudden change in ticket cycle time. Tickets that used to clear in three days suddenly taking 10 is a velocity problem with a capacity root cause more often than not. The third is a turnover event at the agency. If the lead developer on your account leaves the agency, you should be in a real conversation about replacement within five business days. The fourth is a billing surprise. If the invoice in month four is 30 percent higher than month three with no scope change, you need to understand who worked and on what.
When you escalate, escalate to the agency’s account director, not just your project manager. Project managers are often as much in the dark as you are. The account director can pull the staffing numbers and the financials in the same conversation. Bemeir’s internal rule is that capacity conversations get the practice lead in the room within 48 hours of being requested. That should be your bar with any agency you hire.
Right-sizing capacity for the work
Not every Adobe Commerce project needs the same staffing profile. The right capacity depends on whether you are in active build, in stabilization, or in run-rate maintenance.
In active build, you typically want at least three developers committing weekly, with a senior architect carrying the system-level decisions, a mid-level developer driving feature work, and a junior or mid-level developer pairing on it. Less than three named heads usually creates bus-factor risk you should not be carrying. In stabilization, the right capacity drops to two named heads on a 50 percent allocation each, primarily focused on bug fixes and performance work. In run-rate maintenance, one senior developer plus on-call rotation can be enough, especially if the codebase is healthy and the integrations are stable.
The agencies we respect have explicit conversations about which phase you are in and what staffing matches. The agencies we have replaced tend to keep the active-build staffing model long after the active-build phase ended, which is great for their revenue and bad for your finance team. If you are evaluating capacity across Bemeir’s Magento engineering practice or other Hyvä, Shopify Plus, and Shopware projects, the same phase-aware framing applies regardless of stack.
What to do this week
You can start the capacity conversation tomorrow without renegotiating anything. Pull the last 90 days of commit data. Ask your agency for the named heads and allocation breakdown. Compare the two. Build the scorecard. Schedule the monthly review.
The point of all this discipline is not to micromanage. It is to make sure the staffing model in the proposal is the same as the staffing model in production, and to catch divergence early enough that you can correct course without losing a quarter. The agencies who run engagements well will appreciate the rigor. The ones who do not will tell you with their reaction. Either way, you will have the information you need to make a decision that is rooted in evidence rather than in vibes.
