Phase 2 · Partnership Proposal · May 2026

Inside our process.
No spin. No hidden hours.

A transparent look at how your Open edX Academy is built — what a “small” change actually costs, where Phase 1 hours went, and the concrete shape of Phase 2 we’re proposing to make it calmer, faster, and predictable.

Prepared for Jamie Madden · n8n.io
10 repos · 6 envs · 1 platform
Authored by Raccoon Gang
n8n-297 · live trace
09:14SlackClient: "make the Discussions font a bit bigger"
09:18TriageRepos affected: 3 · Risk: low · MFE + Legacy
09:42DesignToken bump 14 → 15 in Paragon theme
10:30Backendtutor-contrib-rg-conf · feature flag added
11:55Frontendfrontend-app-discussions · MR opened
13:20Themetutor-contrib-rg-theme · dark + light pass
14:05DevOpsTutor plugin v2.4.1 → tutor-deployment
15:10QADev + Stage smoke · regression suite green
16:24ReleaseTagged. Demo Friday.
$await sign-off
TL;DR — what we propose

From reactive iteration
to proactive partnership.

Phase 1 shipped a real product. We learned where our process held up and where it strained. Here’s the shape of Phase 2 — six commitments, each tied to a specific friction point. The rest of the page explains why each one matters.
2–3 weeks

Discovery phase upfront

A structured UX walkthrough before any code is written. Catches ~70% of change requests before they become engineering work.

Per feature

Fixed-price blocks

T&M for maintenance and reactive work. Fixed price for any defined feature with clear acceptance criteria. You know the cost before we start.

Already in place

Weekly demo cadence

Bi-weekly sprint demos show working features. You see progress in real time, not in invoice form three weeks later.

Live dashboard

Transparent CR log

Every hour is traceable to a decision. Hours-by-feature, open change requests, releases — all in a read-only client view.

Always explicit

15–20% iteration buffer

Built into every estimate. Honest about reality, not hopeful. No more silent absorption when scope evolves.

Both ways

Response-time SLA

We respond within agreed windows. You respond on blockers within 48 hours. Protects both teams from idle, billable cycles.

Part 1 — Anatomy of an Open edX feature

When you say “just make the font bigger,”
here’s what actually happens.

Twelve concrete steps. Each one has a name, a person, and a paper trail. The reason a “simple” request rarely takes an hour is not estimation drift — it’s the underlying architecture of Open edX itself.
Triage
scope · risk
Investigation
POC · spike
Design
Figma if visual
Backend
Django plugin
Frontend
MFE component
Theme
tutor-contrib-rg
Tutor
plugin · config
DevOps
build · deploy
Manual setup
waffle flags
QA
test · regression
Review
MR cycles
Release
tag · prod
Real example · n8n-275

“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.

Open edX is not one codebase. It’s ten.

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.

breakdown.tsv
01
Investigation
Why does the link go nowhere? Default Open edX bug in Teak release
1h
02
Decision
Patch upstream behavior via plugins, don't fork core
0.5h
03
Backend
Config changes in tutor-contrib-rg-conf · 2 MRs
4h
04
Frontend
Forks of frontend-app-account (2 MRs) + frontend-build (1 MR)
4.5h
05
Theme
Adjustments in tutor-contrib-rg-theme · 2 MRs
2h
06
DevOps
Updated tutor-deployment for new plugin versions
1.5h
07
edx-platform
Single commit fixing core behavior
1h
08
Manual setup
Waffle flag config on dev, stage, prod
1.5h
09
QA
Test on all three envs, dark + light mode
2h
10
Review + bugfix
Internal cycles
2h
11
Release
Tagging, deploy, smoke test
0.75h
Total6 repositories touched20.75h
Part 2 — Architecture

Every theme change is double work by definition.

Open edX is mid-migration from Legacy Django templates to MFE (React micro-frontends). Both stacks exist on your platform — different pages use different ones. This is upstream architecture. The foundation is migrating over the next 2–3 releases.
learn.n8n.io
Legacy
learn.n8n.io
Django templates
MFE
apps.learn.n8n.io
React micro-frontend
Shared design tokens
Paragonrg-themebrand-openedxdark mode
Legacy stack
Django templates · Mako · Sass
  • Course content
  • Studio admin
  • Some checkout flows
  • Legacy survey blocks
MFE stack
React · Paragon · webpack
  • Learner dashboard
  • Profile · Account
  • Learning experience
  • Discussions · Communications
What this means for your invoice

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.

Part 3 — Patterns from Phase 1

Three things worth naming
honestly.

Phase 1 was a successful launch — Teak deployment, custom certificates, external assessment API, dark theme, programs, and 11 client-requested change requests. But we saw three patterns. We’re putting them on the table so we can fix them together.
A

Polish-on-the-fly change requests

11 tracked CRs. Real UX issues. Discovered during testing — expensive in delivery.

#Change requestEstActual
134
Enroll button wording for Invite Only
n8n-134
5h1.25h
225
Add n8n-demo component into header
n8n-225
16.5h14h
268
Navigation links size
n8n-268
2h8.25h
275
Fix Notifications link in Account Settings
n8n-275
10h20.75h
What it tells us: no upfront UX walkthrough surfaced these before code. Discovering them in testing is legitimate — but expensive in a delivery phase. Phase 2 starts with 2–3 weeks of discovery to catch ~70% of these first.
B

Communication intensity

Estimated 92h. Actual 198h. We underestimated. We’ve corrected this in Maintenance — and here’s the structured cadence we propose.

Slack triage
Async · same-day
Weekly status
30 min · Mondays
0.5h
Sprint demo
Bi-weekly
1h
Strategic review
Monthly
1h
~3.5h / week of structured time

Anything beyond — ad-hoc, billed transparently. We default to writing over calling: 80% of questions resolve async without a meeting.

In the dashboard you’ll see communication hours vs delivery hours. If it creeps up, we both notice early.

C

Hidden scope evolution

Dark theme — initially scoped at 6h as standard theming, became a 200h custom feature. We absorbed the difference. That was the right call to maintain trust — but you never saw the true cost.

Going forward, we’ll surface scope evolution explicitly — even when we plan to absorb part of it. You should have full visibility into what’s “in the box” vs what’s a customization. No surprises in either direction.

Part 4 — Your pains → Our solutions

Six friction points.
Six concrete fixes.

For each pain you’ve raised, we lay out — honestly — why it happens and what we propose to do about it in Phase 2. Click any card to expand the detail.
Why it happens
  • ·Open edX features genuinely have hidden multi-repo costs
  • ·Some Phase 1 estimates were intuitive, not decomposed
  • ·Change requests stacked on base scope without a clean budget line
What we propose
  • Decomposed estimates by default — every ≥ 8h feature gets a BE / FE / Theme / DevOps / Setup / QA / Docs / Release breakdown
  • 15–20% iteration buffer explicit in every estimate
  • Fixed-price blocks available for defined features; T&M for maintenance
  • Pre-development review for any feature ≥ 16h — you approve the decomposition before clock starts
Why it happens
  • ·You're often traveling — async transparency wasn't strong enough
  • ·YouTrack is internal; you saw the result, not the live state
  • ·Invoices aggregated work without per-feature spend
What we propose
  • Live client dashboard: sprint scope, hours burned per feature, budget remaining, open CRs, upcoming releases
  • Monthly burn report with feature-level breakdown, sent by email for your records
  • Pre-release demos so you see the work before approving the hours
Why it happens
  • ·Without upfront UX discovery, you find issues during testing
  • ·Each CR runs the full development cycle, even if visually small
  • ·Small CRs (font, copy, layout) feel like 30 minutes but rarely are
What we propose
  • Discovery phase upfront (2–3 weeks) — walk through every screen, every workflow, every field
  • Change request batching — bi-weekly polish releases share one QA cycle and one invoice line
  • CR triage with your input before dev — you decide if it's worth doing now, later, or never
Why it happens
  • ·The Full Start Package includes base solutions, customizations on top are unbounded
  • ·The line between 'configuration' and 'customization' isn't always obvious
  • ·Dark theme is the clean example: standard theming is config, dark mode is customization
What we propose
  • Box-solution checklist — a living document showing exactly what's included by default
  • Explicit customization signal in every triage: [BOX] included · [CONFIG] in-scope tweak · [CUSTOM] needs CR
Why it happens
  • ·Async updates in Slack get lost in travel
  • ·Sync meetings require you to be present at fixed times
  • ·We don't always know which decisions need your input
What we propose
  • Structured async updates — weekly digest: shipped · in progress · blocked · needs input. 5-minute read.
  • Decision matrix — what RG can decide unilaterally vs what needs your sign-off
  • Time-bound responses: 'reply by Friday or we proceed with option A' protects velocity from time-zone gaps
Why it happens
  • ·198h logged in Phase 1, estimated 92h
  • ·Maintenance has used ~70h on communication in 2 months
  • ·T&M means every meeting is billed — which compounds when reactive
What we propose
  • Structured cadence (Pattern B above) — predictable, time-bounded, mostly async
  • Pre-meeting agendas always — no 'let's talk' sessions that turn into 90 minutes
  • Triage in Slack, not on calls — escalate to call only when needed
  • Visible communication budget in the dashboard — if it creeps up, we both notice early
Part 5 — How Phase 2 could look

A concrete shape.
Five months, three tracks.

Discovery upfront, three delivery sprints with bi-weekly demos, then maintenance. The structure isn’t the value — the change is what we do before code starts.
JunJulAugSepOct
Discovery
Track
UX walkthrough
Requirements doc
Estimate + fixed blocks
Delivery
Track
Sprint 1 · Foundation
Sprint 2 · Core features
Sprint 3 · Polish + QA
Maintenance
Track
Ongoing support
Aspect

What changes vs Phase 1

Six structural shifts — none of them framework. Each one ties back to a friction point above.
Discovery
Skipped — went straight to delivery
2–3 weeks upfront
Estimate model
T&M throughout
T&M maintenance · fixed for defined features
Communication
Ad-hoc, on demand
Structured cadence + async digest
Transparency
Internal YouTrack + monthly invoice
Live dashboard + monthly burn report
Change requests
Each handled standalone
Batched into polish releases (every 2 weeks)
Scope evolution
Sometimes absorbed silently
Always surfaced, even when absorbed
Part 6 — Our commitment

Within 2 weeks of Phase 2 kickoff.

A clean handshake — five things we deliver, five things we ask in return. No vague promises. Each item has a definition of done.
What we'll do
On us, in writing, with dates.
  • Publish the box-solution checklist
  • Stand up the live client dashboard
  • Schedule the structured weekly / bi-weekly cadence
  • Deliver the discovery phase plan with clear deliverables
  • Send the first monthly burn report
What we ask from you
To make this work, we need:
  • Active participation in the 2–3 week discovery phase
  • Response within 48 hours on blocker-level decisions
  • Designated point person for design decisions
  • Honest feedback when the cadence isn't working — we'll adjust
  • Trust in the change request process — even small UI tweaks need it

Years, not phases.

We’re proposing this partnership because we want to build the n8n Academy with you over the long run — not just deliver another phase. Let’s talk about what makes sense for you.

Schedule the conversation
FAQ

Questions we’ve heard.
Answers in writing.

The seven questions that came up most often during Phase 1 conversations — answered without spin, including the ones that don’t flatter us.
Honest answer: we should have. By the time we realized the scope, you had already invested expectation in it being delivered. We chose to absorb the cost internally rather than reopen the discussion mid-flight. In retrospect, a clean conversation upfront would have been better — for both of us. Going forward, we’ll surface scope evolution immediately, even when we plan to absorb part of the cost.