Get in touchAdobe Experience Manager Development
Enterprise platforms that don't fight their editors.
AEM gets heavy in familiar places: dialogs authors avoid, integrations nobody dares touch, migrations parked halfway. I build and repair the platform until releases are unremarkable — from AEM 6.x and Managed Services to Cloud Service, headless included.
5+
years in AEM
3
global platforms
∞
component reviews
Who it's for
- Enterprise teams taking AEM from 6.x, on-prem or Managed Services to Cloud Service.
- Digital teams that need an extra senior pair of hands on components, templates or integrations.
- Organisations moving to headless or hybrid delivery with Content Fragments and GraphQL.
- Teams where authoring quietly became the slowest part of the release.
What I bring
06 deliverablesComponents editors open
(01)Core Component-based building blocks with dialogs that explain themselves — no wiki required.
Migrations that land
(02)Assessment, refactoring, content transfer and go-live support in one plan, with checkpoints you can see.
Headless, without drama
(03)Content Fragments, Experience Fragments and GraphQL that keep their shape as content multiplies.
Integrations with receipts
(04)Commerce, search, CRM and campaign tools connected once, monitored and documented.
Caching you can reason about
(05)Dispatcher and CDN rules with numbers attached, so one release doesn't surprise the next.
Tests your team keeps
(06)AEM Mocks, PR checkpoints and a CI pipeline that catches regressions before an author does.
What work is covered
- AEM Cloud Service and 6.1–6.5, including on-premise and Managed Services installs
- Classic, hybrid and headless setups — SPA Editor and Remote SPA included
- Multi-site and multi-tenant platforms on MSM
- Content and Experience Fragments, Dynamic Media, GraphQL endpoints
- Core Components, custom components and AEM Mocks test suites
- Dispatcher, SSI/ESI and CDN configuration
- Authoring design: dialogs, policies, content models
How it works
4 steps- 01
You bring the mess
Half a spec, a bug list, or a migration that stalled — all valid starting points.
- 02
I cut the first slice
One small piece with real value, agreed in writing before anything else moves.
- 03
Ship in the open
Working software every week, reviewed with your team — not a reveal at the end.
- 04
Hand over the keys
Code, docs and conventions stay with you; I stay reachable if you want that.
Questions
What does an AEM engagement cost?
Every scope is different, and a price list would be fiction. We talk for twenty minutes, then you get a written quote: fixed for clear-cut work, phased when parts are still fuzzy, monthly for ongoing support.
Which versions do you cover?
Cloud Service and 6.1 through 6.5 — on-premise, Managed Services, multi-site included. If you're stuck between versions, that's usually the first thing I plan.
Can you work inside our team?
Yes — your process, your reviews, your release cadence. The difference is what stays behind: conventions, tests and documentation that survive my exit.
Do you handle Cloud Service migrations?
It's a recurring job: assess with Adobe's tooling, refactor what Cloud Service rejects, plan the content move, then sit through go-live. No hand-waving at the risky parts.
Is it only AEM?
No. Edge Delivery Services, Java services and micro frontend architecture get the same treatment.
How do we start?
A short call and a paragraph about the problem. If we fit, you get a scope and a date — both small enough to test each other.
Brief
Send the
brief.
A half-formed problem works. Pick the closest reason and write three sentences — you get the smallest useful first step back.
Why are you reaching out?
Tell me about the platform, the timeline and your team.