I work as a contract Open edX developer and administrator, and I operate these platforms in production. Upgrades across named releases, incidents root-caused down to the index and the kernel setting, Tutor plugins, micro-frontends, and the unglamorous account-and-enrolment work that never makes it into a case study.
Every public claim on this page links to a public repository, a published article, or a dated artifact. Figures from private client work are labelled as private, because a stranger cannot re-run them. Where a client has not been named, they are described by sector instead.
Years of experience are hard to check from the outside. These are the parts a stranger can open in a browser and confirm, including the ones that are smaller than they sound.
Each of these is a description of work that exists, not a service menu. Most of the figures in these cards come from private client work, so unlike the list above they cannot be re-run by a stranger. The second paragraph in each card is the part that usually gets left out.
Operate
A scripted daily health sweep of a live Open edX stack: ten read-only probes across application telemetry, the host, every Tutor container, Celery queue depth per queue, stuck instructor tasks, MongoDB, MySQL, cron freshness, the SSO gateway and cloud alerts, scored against an eighteen-row threshold rubric and filed as a dated digest.
The routine is written as a read-only contract: an explicit allowed-verb list, an explicit forbidden list covering container restarts, Redis writes and any ORM save or delete, and failure-isolated probes so one broken check never swallows the report.
Upgrade
An eleven-hop upgrade path from Hawthorn to Sumac, scripted as seventeen numbered shell scripts with the Tutor release pinned for every hop, iterated against real runs rather than written once and hoped over.
Each hop is a data migration, not a config bump: dump, drop and recreate with foreign key checks disabled, metered import, then reindex_course, simulate_publish and generate_course_overview, and finally an automated row-count check on auth_user, course enrolments and certificates. Separately, a migration off Open edX's deprecated slash-separated course IDs on a large single course, moving enrolments, certificates, persistent course and subsection grades and hundreds of thousands of courseware state rows, using .iterator() and bulk_create to keep it out of memory and get_or_create so a re-run could not double-write, with a companion MongoDB migration that re-parents the discussion comment tree onto the new course ID, backup first.
Investigate
Courseware pages taking two to three seconds at near-zero CPU, during quiet hours. Ruled out the obvious suspects with evidence, then found it in MySQL: a completion table whose index had grown to more than twice the size of its data across millions of rows, with insert latency in the tens of milliseconds and a multi-second lock-wait tail.
Also in that investigation: Transparent Huge Pages left at 'always' on the host against MongoDB's documented requirement of 'never', with the runtime fix and the systemd unit to survive a reboot. Fixes staged by risk, cheapest and safest first, each with its revert. Elsewhere, a self-inflicted outage class root-caused to unbounded BuildKit running every micro-frontend webpack build at once, fixed by constraining the builder rather than by adding RAM.
Extend
Django plugins registered through the platform's own lms.djangoapp entry point rather than forks of edx-platform, which is how Open edX intends to be extended and what makes the next upgrade survivable.
Four such plugins on one platform alone: certificate overrides, runtime behaviour patches, a certificate integration and a reporting app. A registration extension too, though that one hangs off the REGISTRATION_EXTENSION_FORM hook rather than an entry point. Plus an XBlock on PyPI with signed playback, direct-to-CDN upload from Studio and encryption of credentials at rest.
Theme
Comprehensive themes for the legacy Mako surface and Paragon brand packages for the micro-frontends, which are two different systems that have to agree, plus forks of the shared header and footer components when restyling is not enough.
Including a right-to-left, fully localised deployment: layout direction driven off Mako's dir_rtl, a localised font stack, and translated course-discovery facets.
Integrate
An SSO plugin that mounts custom authentication endpoints into the LMS and brokers entitlement redemption, licence acceptance and profile sync against an external identity gateway. 136 of its 183 commits are mine, over two years and still shipping; the repository is private.
Also: Open edX configured as an LTI tool provider with the cross-site cookie and CSP plumbing that actually requires, JWT-authenticated enrolment endpoints, and a certificate integration that replaces native PDFs with issued digital credentials.
Platforms I have run, not just built
One is named because my commits sit in a public GitHub organisation and anyone can open them. The other two are live engagements described by sector and scale.
Free professional design and development courses, run on Open edX. Over five years of recurring work on one platform, across three fundamentally different deployment models: the Python 2.7 and Django 1.11 native Hawthorn install, the Tutor-on-Docker era, and the Redwood micro-frontend era.
199 commits across ten public repositories in their GitHub organisation, attributed by GitHub's own contributors API on each repository's default branch. Second of four contributors on the 328-file comprehensive theme; top contributor on its certificate integration, its registration-form fork and its reporting plugin.
Merged 62 pull requests into that theme, 30 of them staging-to-production release promotions onto its hawthorn/production branch. That is the release-gate role, not just commit access.
Built its Accredible certificate integration and carried it across a five-year platform gap, including the Python 2 to Python 3 port.
Four Open edX Django plugins rather than a forked platform: certificate overrides, runtime behaviour patches, a reporting app with scheduled CSV exports, and the certificate integration above.
Contributed to the Redwood-era micro-frontends as well as the legacy stack: certificate-generation modal, course-celebration gating, failed-exam messaging on the final exam page, and registration-flow changes in the authentication app.
The marketing site is still live and still credits Open edX in its footer, but it now announces it has stopped offering credentials, so the engagement is described in the past tense.
A US professional-education publisher
2024 - present
A single-tenant Open edX Redwood platform on Tutor 18, ten long-running services on Azure, where I am the person who runs it as well as the person who writes for it. Still shipping in August 2026.
517 of 572 commits on the Tutor plugin that carries every customisation the platform has: nineteen patch points across LMS and CMS Django settings, feature flags, the reverse proxy, both image build stages, and git patches applied to upstream at build time. The repositories and documents behind this card are private, so its figures cannot be re-run by a stranger.
56 of 91 commits on the Terraform repository, also private: 120 declared resources across production, UAT, a second production group and analytics, including the full CDN definition.
Backups I would be willing to restore from, because I wrote the restore: two daily jobs, credential-free uploads under the VM's managed identity, append-only sync so a source deletion cannot propagate, and two runbooks covering four recovery scenarios each with a dry-run preview and an estimated 45-minute rebuild.
A written register of what disaster recovery still does not cover, kept next to the runbooks, so the gaps are known rather than discovered during a restore. Documented gaps beat a clean-looking posture that nobody has tested.
Problem management as well as incident response: an alert rule firing four to ten times a day against zero to two actual server errors, flagged across consecutive daily digests with a concrete next step rather than muted.
A 1,454-line engineering onboarding and operations manual, and a 408-line CDN cutover runbook with the rollback snapshots taken before step one. Both are private client documents.
Sector and dates only. No client name, hostname, resource name, version pin, learner figure or open security gap from this engagement appears anywhere on this site.
A US non-profit workforce-development platform
2026 - present
Open edX on Tutor 21, the Ulmo release: a sixteen-container stack with the Aspects analytics plugin, inherited and now operated day to day.
Diagnosed a four-month enrolment failure from the client's private logs: 75 server errors between March and July, 71 of them from real learners, traced to enrolment deep links pointing at retired course runs.
Back-ported a published Open edX security advisory, GHSA-2843-x998-f8r2, an unvalidated redirect in the survey views, into the client's production image build.
Built the platform's nightly backup job and an unattended read-only health monitor that scores only user-facing failures, with an access-log liveness backstop so a zero-error count from a dead logger is reported as unknown rather than as healthy.
Sector only, for the same reason as above.
Named releases I have carried a platform through
Hawthorn to Sumac exists as seventeen pinned upgrade scripts, iterated against real runs and carried to Redwood, with a row-count check on users, enrolments and certificates at the end of each hop. Current production work sits on Redwood and Ulmo.
HawthornIronwoodJuniperKoaLilacMapleNutmegOlivePalmQuinceRedwoodSumacUlmoVerawood: read, not run
What people who worked with me say
Seven LinkedIn recommendations, reproduced in full rather than trimmed to the flattering clause. Each name links to the profile that wrote it. The first two name Open edX; the rest are about engineering, support and communication.
While Amir was at Appsembler, I worked as the Product Development Manager for Open edX at the Open University, with Appsembler acting as the supplier for this platform for us.
Amir handled many of our development requests and defect management. I was always blown away by how quickly and professionally Amir handled our issues.
Always polite and willing to help, Amir was a credit to Appsembler, and helped us feel secure in our contract knowing that he was there handling our development and support.
Product Development Manager at The Open University
Client, The Open University · Open edX
It was a pleasure to work with Amir on numerous projects that involved Open edX as the core component of Appsembler’s SaaS learning platform, from 2017 to 2021. Amir has been a key driving force behind everything happening technically with our enterprise customers. In addition to his technical expertise, Amir is reliable, self-driven and an excellent communicator in a distributed working environment. I highly recommend Amir for your team of developers or consultants.
Amir is a type of engineer that I have come to believe is rare in the workforce: unassuming, consistent, reliable. If you have ever managed a team, this kind of description is very exciting. I would not hesitate to bring Amir in to bolster any engineering team that I was running. He showed great ability to take ownership over his work, be open to input, discuss things, and I could trust his expertise when it came to e-learning systems. That is invaluable. 10/10 would recommend.
If you have chance to work with Amir, take it. I had the pleasure of working with Amir for years, and he was one of the most thoughtful, focused engineers on my team. He balances customer needs with architectural decisions well—I could always confidently put him in customer calls, even in difficult situations, and know that he’d handle the situation with poise and come up with a solution that worked well for the customer and our engineering team. He also has a excellent way of communicating technical concepts, whether through technical writing or in presentations—give him the opportunity to do so, and your team will benefit greatly.
I had the pleasure to work with Amir during the Xmas break. I was a client to Amir’s company and had several strategic questions which required a speedy response in order for us to plan our training program for the coming new year. Amir who was in the engineering team, took the initiative to talk to me directly during Xmas break and answer all my questions. He is extremely knowledgeable and professional, and I hope to work with him real soon.
Knowing Amir, he probably hasn’t sold himself as heavily as he deserves, so allow me to elaborate and make him cringe. Amir is special. Give him a task and it gets done. Give him a problem and it gets solved. There is literally no challenge that I have ever seen him fail to absolutely smash out of the park, all while being a humble, gentle human being. He forms strong bonds with customers and technical partners, who know they can trust him to hold up his end and support them, and he does so unflinchingly. He says in his bio that he gets to do incredible things every day, but that’s not quite true - Amir makes incredible things happen, because Amir himself is incredible. You want him on your team.
Amir has worked on various technical writing and software development projects over at TestDriven.io for the past several years. His work is top notch. He’s an excellent developer and communicator. I highly recommend him. He’s a good human, someone you definitely want on your team.
A named number of days a month against your platform, or a fixed-scope project: a release upgrade, an inherited-platform audit, an incident nobody has been able to close, an SSO or LTI integration, a theme that has to survive the next upgrade.
You get the person who does the work. There is no bench behind me and no junior handoff, which is a real constraint as much as a selling point: I take a small number of engagements at a time.
Remote · Quito, Ecuador (UTC-5) · overlaps the US working day and European afternoons
Hosting, named-release upgrades on a calendar you can show an auditor, advisory patching, backups with restore runbooks that have actually been read, and the daily health routine described further up this page.
No. I run Cubite, so I take Open edX work on a contract or fractional basis: a named number of days a month, or a fixed-scope project. In practice that suits an Open edX platform better than a full-time hire, because the load is spiky. Upgrades and incidents need real depth for a few weeks; the months in between need a steady hand and a daily check, not a full-time salary.
Which Open edX releases have you actually run?
Hawthorn through Ulmo. The eleven-hop upgrade path from Hawthorn to Sumac exists as seventeen pinned shell scripts because it was iterated against real runs rather than written once and hoped over, and it was carried through to Redwood. Current production work sits on Redwood (Tutor 18) and Ulmo (Tutor 21). I have read Verawood closely enough to know that frontend-base under OEP-65 means operators now maintain three theming systems rather than two, and that the instructor dashboard replacement is on by default, but I have not run it in production and do not claim to have.
Can you take over a platform somebody else built?
That is most of what I do. The first deliverable is usually not a change, it is an inventory: what release, what is patched, what is forked, what is only in someone's shell history, and what breaks on the next upgrade. Two of the three platforms described above were inherited.
Do you do the unglamorous parts?
Duplicate SSO accounts colliding on the email unique index. A learner's progress moved between two course runs with a read-only preflight, a pre-state export and a rollback record naming the exact primary-key ranges. Orphaned bulk-email tasks left in QUEUING since an earlier incident. A dbt model failing the same way four mornings running. Disk creeping toward its warning threshold. That is the job, and the artefacts for all of those exist.
Why is there no uptime percentage or SLA table on this page?
Because I do not have an instrumented uptime record I could stand behind, and a number I cannot reproduce is worth less than no number. What exists is a scripted health routine filed as dated reports, with a retained run of daily digests, cloud alert rules on server errors and request duration, and written restore runbooks. That is what is claimed, and no more.
What can you not do?
I have one commit merged upstream in the openedx organisation, so I am an operator and an integrator, not a core platform maintainer, and the page says so where it counts. I have not run Verawood in production. I have no formal on-call rotation or ticketing-system record to show, because on client engagements those live in the client's tracker rather than mine.
Tell me what your platform is doing to you
Thirty minutes, no charge. If the honest answer is that you do not need me, or that you should not be on Open edX at all, you will get that answer.
