How to Choose an AEM Partner: Agency, Boutique, or Independent Architect

Match the partner to the shape of the work. A large systems integrator is right for multi-country programmes that need dozens of people and procurement-grade structure. A boutique is right for a defined build with a small experienced team. An independent architect is right when the need is judgment rather than capacity: assessments, migration decisions, rescues, and owner's-side review of other vendors' work. The strongest setups often combine two, an architect on the buyer's side of the table and a delivery partner across it. The evaluation questions and red flags below apply to all three.

When is a large systems integrator the right choice?

Choose a large SI when the programme is genuinely large. Multi-country rollouts with parallel workstreams, a dozen integrations, offshore-scale content production, and a two year calendar need staffing elasticity that only a big bench provides. If people rotate off, the SI backfills; a smaller partner cannot. SIs also carry breadth across the wider Adobe stack (Analytics, Target, Journey Optimizer, Commerce) under one contract, which matters when the AEM build is one piece of a platform programme. And when your procurement process demands audited security postures, framework agreements, indemnities, and support obligations around the clock, the SI is often the only candidate that can sign.

The costs of that shape are structural, not accidental. Team quality varies widely inside the same firm, and the people who impressed in the sales cycle are rarely the people who write the code. Delivery runs on a staffing pyramid: a few experienced leads over many juniors, which is how the commercial model works and why velocity per head is lower than the headcount suggests. Decision paths are long, and the commercial model rewards scope growth. None of this makes SIs wrong; it makes them wrong for small and mid-sized work, where you pay the overhead of scale without needing the scale.

When does a boutique fit better?

Choose a boutique when the work is a defined delivery: a site build, a migration, a replatform of known scope, and the team needed is roughly three to eight people. The boutique's advantage is density. The engineers who scoped the work deliver it, the principals stay close to the code, and decisions that take an SI a steering committee take a boutique a conversation. For the majority of AEM projects, which are mid-sized, this is the best value shape available.

The limits are the mirror image. Bench depth is thin, so a departure mid-project hurts, and a second concurrent programme may be beyond them. Coverage across the wider Adobe stack is usually partial. Round-the-clock support, multi-language content operations, and heavy compliance paperwork strain a small firm. A boutique that says yes to all of that is answering the sales question, not the delivery question, and it is worth probing which.

When do you need an independent architect?

Choose an independent architect when the scarce input is judgment, not hands. The work that fits:

Assessment and decision support. Whether to migrate to Cloud Service, whether a codebase is salvageable, whether AEM is even the right platform for the workload. These are two week engagements that steer a platform's most expensive decisions, and they want an advisor with no delivery revenue riding on the answer.
Owner's-side review. Reading an SI's proposal, estimate, or architecture before you sign it, and reviewing what gets delivered against what was promised. A delivery partner cannot audit itself; someone on your side of the table can.
Rescue. Programmes that are late, over budget, or slow in production usually suffer from a small number of architectural decisions. Finding and fixing those is diagnosis work, and diagnosis is an individual skill, not a team sport.
Architecture continuity. A part-time architect who owns the technical direction across vendor changes, so knowledge of why the system is shaped the way it is survives each contract ending.

The limits are equally plain. One person does not deliver a programme, and a good architect will say so rather than absorb work that needs a team. Availability is finite, and continuity depends on one calendar. Anything that needs sustained parallel build capacity needs one of the other two shapes alongside.

What should you ask any candidate?

The same questions expose the quality of all three shapes.

Who exactly will do the work? Names, not roles. Ask how much of their time is committed and what happens to the engagement if they leave. Refusal to name people before signature tells you the staffing is not decided.
How do you estimate? A credible AEM estimate for migration or remediation work rests on evidence from your environment, such as a Best Practices Analyzer report or a codebase review, not on a form filled in during a sales call. Ask what inputs their number needs.
Show me comparable work. Not logos: a comparable problem, what they decided, what went wrong, and what they would do differently. A candidate with real history has failure stories and tells them without prompting.
Who owns architecture decisions, and how are they recorded? Someone specific should own them, and they should exist in writing. A partner without an answer will leave you a system nobody can explain in three years.
What happens when the scope turns out to be wrong? It will be. You are listening for a process (re-estimate against evidence, re-plan openly), not a posture of confidence.
What does handover look like? Documentation, code ownership, repository access, and the cost of leaving. Partners confident in their work make leaving easy; the exit terms tell you who expects to be kept by choice and who by lock-in.
How do you keep the platform current? For AEM specifically: their stance on Cloud Service constraints, upgrade posture, and what of their previous builds passed Cloud Manager's quality gates. Certifications are table stakes; shipped and operated platforms are the signal.

What are the red flags?

A fixed price before anyone has read your code or your BPA report. Either the number is padded or the pain arrives later as change requests. In AEM work, evidence precedes estimates.
A rebuild recommended by default. Rebuilds are sometimes right, but a partner who reaches that conclusion before assessing what exists is selling the project they want to run.
No questions about your content, integrations, or authoring team. Sites are the visible part; content structure, integrations, and author workflows are where AEM projects succeed or fail. A candidate who does not ask is estimating the visible part.
Everything is yes. Real capability has edges. A partner who accepts every requirement without pushback either has not understood them or plans to renegotiate once you are committed.
The team you met disappears after signature. Ask directly whether the people in the room will be on the project, and get it in the contract if the answer matters to you.
Licence resale steering the advice. When the partner's margin improves with your Adobe spend, recommendations to expand the stack deserve independent scrutiny.
No written handover plan. Absence of an exit story is a plan for dependency.

How do the shapes combine?

The combinations are often stronger than any single choice. An independent architect on the buyer's side plus an SI or boutique delivering is the classic pairing: the architect writes the requirements, reviews the estimates, and audits the delivery, and the delivery partner does what it is good at, at scale. A boutique build with an SI taking over run and support is common where support obligations outgrow the builder. And a second opinion on a large decision, bought from someone outside the delivery contract, costs a rounding error against the programme it protects. The pattern underneath all of them: keep the party that advises you separate from the party that profits from the advice.

akenside.ai works in the third shape, as an independent architecture practice for Adobe Experience Cloud.