Inside our process.
No spin. No hidden hours.
A transparent look at how Open edX features get built — what a “small” change actually costs, why architecture drives the hours, and the methodology behind our estimates. Built from production work on the n8n Academy platform.
The methodology
behind our estimates.
Decomposed into 12 components, each touching 2–4 repositories.
Synchronized tagging across edx-platform, theme plugin, conf plugin, brand-openedx, MFE forks, and tutor-deployment.
MFE (React) + Legacy (Django templates) duplication until upstream migration completes.
The rest of this page shows the architecture and process that produce these numbers — and lets you build estimates yourself.
When you say “just make the font bigger,”
here’s what actually happens.
“Fix Notifications link in Account Settings”
From your side: a broken link, should take an hour.
Estimated 10h. Actual 20.75h. Why? The upstream bug ran deeper than the surface symptom — it touched account settings, MFE config, and theme rendering at once.
We maintain forks of edx-platform, tutor-contrib-rg-conf, tutor-contrib-rg-theme, frontend-component-header, frontend-component-footer, frontend-build, frontend-app-account, platform-extensions, brand-openedx, and your dedicated programs-catalog service. A “small” UI change often spans three or four of these.
Every theme change is double work by definition.
- —Course content
- —Studio admin
- —Some checkout flows
- —Legacy survey blocks
- —Learner dashboard
- —Profile · Account
- —Learning experience
- —Discussions · Communications
A change to the dark theme toggle, the header avatar, or a typography token must be applied twice — once in Legacy templates, once in React MFEs. It’s why we invested in tutor-contrib-rg-theme early: it now shares Paragon design tokens between both, and the same investment will keep paying down in Phase 2.
Build your own estimate.
Type dev hours. See the full cost.
The dev hours you already have in mind — pure coding time, excluding everything else. Dev-time overhead lines below are computed as a percentage of this number.
Fixed release work. Default uses the low end of the 2–4h per role / release range.
Added on top of dev time, dev-time overheads, and release activities.
Added as a percentage of the running total after PM is included.
Optional. Drop below 1.0 to pad for meetings, context switches, async waits. Off by default — already baked into the category percentages above.
Optional. Push above 1.0 for unknown integrations or new architecture. Off by default — design changes against a locked Figma usually don’t need it.
Every 1h of dev expands into 3.40h of project work once the full process is counted.
Default coefficients use the updated RG model: dev-time overheads are calculated from pure development hours, release activities are fixed hours, PM is added as 10% on the subtotal, and team / project communication is added as 30% on the total after PM. The productive-time and timeline-risk multipliers stay off by default; push them above/below 1.0 only for projects with unusual integration or staffing risk.
What the production work
looked like.
Polish-on-the-fly change requests
11 tracked change requests during Phase 1. Each fully decomposed, estimated, and shipped. The variance between estimated and actual reflects the multi-repo nature of small Open edX changes.
Communication intensity
Phase 1 logged 198 hours on communication against an estimated 92. The structured cadence below reflects the rhythm Open edX projects with active client involvement actually require.
In T&M projects, communication hours are part of the work product, not overhead. Each item — triage, status, demo — produces decisions that affect what gets built next.