Internal strategy · living document

Where LernHive stands — and where it's going.

This page summarises vision, principles, architecture and pricing model in a technical-strategic reading. It's intentionally more matter-of-fact than the landing page and serves internal alignment and partner briefings.

Vision

LernHive is a standalone, modular learning platform — clearer, easier to operate and experience-driven. UX and design are clearly separated from business logic; building blocks instead of one-offs. As its foundation, LernHive runs on the Moodle 5.x platform without forking it — see the Technology section below.

Positioning

LernHive is a standalone learning platform with guided UX, Flavours for typical scenarios and an optional LXP experience. The level system and Explore feed shape the product identity — the underlying open-source foundation stays technically compatible but conceptually in the background.

Seven core principles

1 · Clean foundation The underlying open-source platform stays unmodified. All extensions run through its official extension APIs — no fork.

2 · Function & design separated Business logic in the functional building blocks, visuals in the theme. No mixing.

3 · English first English is canonical, translations follow the conventions of the underlying platform.

4 · Reuse what's proven Existing roles, capabilities, strings and concepts are reused, not replaced.

5 · Simple UX first Clarity beats feature completeness. Guided flows over expert overload.

6 · Flavours = recommendations Starting configurations, not hardcoded modes. Everything stays adaptable, overrides remain traceable.

7 · Release 1 disciplined Scope discipline: R2 ideas must not silently slip into R1. Scope shifts are visible in documentation.

Five product layers

This is how LernHive is cleanly layered. Each layer owns its responsibility and depends only upwards.

Layer	Responsibility
1 · Open-source foundation	Courses, activities, groups, enrolment, roles, reporting, messaging, competencies, language system — from the underlying Moodle 5.x platform.
2 · LernHive building blocks (functional)	Orchestration, guidance, product-specific logic: Flavours, levels, ContentHub, Explore, Audience, reporting, digest.
3 · LernHive theme & UX components	Visual identity, layout shells, Context Dock, sidebar.
4 · Flavour & configuration layer	Recommended starting configurations (School, LXP, later others), override history, partner documentation.
5 · SaaS & partner layer	Operations, managed service, partner sales, flavour-based consulting.

Architecture contract: ADR-P03

The shared UI classes for the building-block surfaces (.lh-plugin-*, .lh-btn-*, .lh-icon-*) and the plugin_shell_header partial live centrally in local_lernhive. All LernHive building blocks therefore render structurally correct under any compatible theme — branded when theme_lernhive is active, neutral under Boost / Boost Union / partner themes.

Flavours — product starting points

Flavour	Priority	Core statement
School	R1	Classic course-based entry, familiar structure, guided UX.
LXP	R1	Explore instead of dashboard, Snacks, Communities, Follow/Bookmark, digest.
Higher Education	later	Academic audiences, course structure, exam UX.
Corporate Academy	later	Continuing education, mandatory/recommended content, reporting.
Association / Membership	later	Associations, member engagement, community content.

Rule

Flavour-specific wording changes stay minimal. Core terminology — Explore, Audience, Follow, Bookmark, ContentHub, Snack, Community — stays stable across all Flavours.

Roadmap

Disciplined core scope

Core-UX + Theme
Level system + feature registry
ContentHub + Copy + Library
Onboarding (Level 1 pack live)
School Flavour
LXP Flavour with Explore, Follow, Digest
Basic Audience rules
3-tile reporting dashboard
Orgchart (productive)
Learning Pathways + Certify (productive)

Refinement & depth

Stronger personalisation
Recommendation logic
Audience Circle UX (visual rule builder)
Content versioning & library lifecycle (update compare, import history)
Expanded reporting (custom dimensions, inactive users tile)
Skills & learning plans (UX layer)
Snack and community course formats
Multitenancy hardening (tenant isolation patterns)
Higher-Ed & Corporate Academy Flavours

Later

Open directions

Higher-Ed, Corporate, Association Flavours
Native mobile app
AI-assisted content creation
Third-party theme integration

Pricing model

Principle

The pricing architecture is set: active users as the only calculation basis, SaaS-only, operated in Germany, GDPR- and ISO 27001-compliant. Concrete per-tier numbers will be sharpened once R1 is in production.

Business model (fixed)

SaaS-only. Managed operation on German servers. No self-hosted option. Keeps security, updates and privacy commitments consistent for all customers.
Active users as the calculation basis. Billed per person who logs in at least once per calendar month. Created but inactive accounts do not count.
Partner-enabled. Sales and rollout run through a partner model. Partners have a dedicated tier with wholesale conditions.
Managed service with documented configuration. The configuration history makes every change auditable and underpins managed-service contracts.

Commitments in every tier

Commitment	Details
DE-Hosting	Exclusively German server locations. No data processing outside the EU. DPA per Art. 28 GDPR provided on request.
DSGVO by Design	Data minimisation, role and permission system, documented retention, Privacy API-based subject access, exports and deletion.
ISO 27001	Operated in ISO 27001-certified data centres. Change/incident/backup/access follow an ISMS. Audit reports and TOMs on request.
Updates & Backups	Platform updates, building-block updates, security patches, daily backups. No separate maintenance contract.
Portable content	At contract end, full data exports in open standard backup formats. No lock-in penalty.

Pricing dimensions

Monthly active users — primary scale driver, tier-determining
Booked Flavours (School, LXP, later others) — enabled within the tier
Add-ons (seminar management, orgchart, later skills/reporting) — flat per instance; included in Enterprise tier
Support tier (Standard, Priority, Partner-Managed) — tier-bound

Tier scaffold

Starter up to 250 active / month

Single schools, small teams
One Flavour (School or LXP)
Standard support
Backups & updates incl.

Professional 250 – 2,500 active / month

Mid-size organisations
Both Flavours (School + LXP)
Extended onboarding
Priority support

Enterprise from 2,500 active / month

Groups, associations, universities
All Flavours & add-ons
Orgchart + seminar admin incl.
SLA, dedicated instance, SSO

Partner-Managed Partner model

Partners with multiple end-customers
Wholesale conditions
Configuration tracking + training
Joint tenant support

The customer-facing version — with calculation basis, trust commitments and FAQ — lives on its own page:

→ Open pricing page

Open pricing questions

Concrete per-tier list prices — only published once R1 is in production and usage curves are available.
Fair-use limits on storage and traffic: qualitative wording or concrete GB thresholds?
Overage billing: flat per 100 additional active users, or linear per head?
Partner margin model: flat wholesale discount or tiered by tenant volume?
Add-on pricing outside the Enterprise band: flat per instance or with a separate user-tier?

Guardrails

For daily product work.

Respect the documentation hierarchy. Product decisions in product/, plugin-local decisions in public///docs/, visual decisions in theme_lernhive.
Keep terminology stable. Core terms must not be renamed per Flavour.
Reuse strings. Existing platform strings first; new strings only with justification.
DevFlow consistency. When a feature changes, all six DevFlow files of the plugin stay aligned.
Scope discipline. R1 targets are not silently extended by R2 ideas.