Online School Website Development: Where the Learning Process Breaks
Online school website development most often runs up against not design, but three places where the learning process breaks.
The first is that the class schedule lives separately from the student's personal account: a teacher reschedules a lesson, but some students are left with the old date, because the calendar, notifications, and course database are updated manually by different people.
The second is the issuance of course access: a manager checks payment against a spreadsheet and opens modules by hand, and with a cohort of hundreds of people, someone inevitably waits a day for access, while someone else gets an extra module.
The third and most expensive is the load at the start of a cohort. On the day enrollment opens, tens of times more people come to the site than on an ordinary day: everyone logs in at the same time, opens the first lesson and video.
If the site is built as a course storefront rather than as a learning platform, it goes down at exactly that moment — when the school has already sold seats and is obligated to hold the class.
The cost of these failures is not in "inconvenience," but in refunds, manual support work, and reputation: a student who couldn't get into the first lesson studies at half strength from then on.
Let's break down how this is closed at the architecture level, rather than with crutches in the admin panel.
What a properly designed online school website delivers
A properly designed school website is built around a single principle: access to a course is a consequence of payment, not a separate administrator action.
The integration of 1C-Bitrix with the accounting system handles this at the event level: once a payment is confirmed, the student immediately gets access to the right cohort, renewal or installment plans extend it automatically, and a refund just as automatically closes it.
Manual operations on a cohort of hundreds of people are reduced to a handful, and they deal with exceptions rather than routine.
What changes in numbers
- Access provisioning: used to take 5-15 minutes per student manually — now it triggers at the moment of payment, without administrator involvement.
- Schedule: a single source for webinars, deadlines, and reminders — discrepancies between the personal account and the email are eliminated by design.
- Peak load: enrollment for a cohort and the start of a webinar are handled without crashes thanks to caching and offloading heavy operations.
- Cohort launch timelines: a new intake is spun up by copying the course structure rather than assembling it from scratch.
Where it breaks down without proper design
A typical mistake is that access is granted manually or by a scheduled script: at the start of a cohort the administrator drowns in requests, some students wait a day, and support gets a flood of inquiries.
The second is that the schedule lives in three places, and the student sees different webinar dates in the personal account and in the email.
The third is that payment and access are not linked, so a refund does not close the course, and the school keeps paying for extra licenses and a spot in the cohort.
We design these integrations before development starts: we describe the events between payment, the accounting system, and the personal account, determine what happens on a payment failure or cancellation, and only then write the code. A website like this survives cohort growth without growing the support staff.
Learning Portal Architecture Options: Comparing Approaches
The choice of architecture determines how the school will live on: where webinar recordings are stored, how course access is counted, and what happens when there is a surge of students on the day a cohort starts.
In practice, we build learning portals using three schemes, and each one addresses its own class of tasks — there is no universal option.
| Option | When it fits | Limitations |
|---|---|---|
| A single portal on Bitrix24 | The school is just starting, the team is small, and webinars, chats, and tasks are needed "out of the box" | Weak flexibility of the public-facing part: the course showcase and cohort landing pages are hard to design to match the brand |
| A website on 1C-Bitrix and Bitrix24 | A public website with a course catalog, payment, and a personal account is needed, while internal work happens in Bitrix24 | Requires linking two circuits: single sign-on, synchronization of payment statuses and access rights |
| A website and an external learning system | The catalog, sales, and content live on the website, while lessons, progress, and assignment checking live in a separate platform | Two interfaces for the student, and careful synchronization of progress and access is needed |
A single portal wins on launch speed: accounts, webinars, and notifications are already connected to each other, and there is no need to build data exchange.
The limitation shows up later — when the school wants a non-standard showcase, complex sales logic, or its own gamification mechanics, and hits the boundaries of ready-made sections.
Linking a 1C-Bitrix website with Bitrix24 provides a flexible public-facing part and a strong internal circuit: sales, payment, and the personal account on the website, while methodologists' work and support happen in Bitrix24.
The price of the solution is integration: single sign-on, exchange of order statuses, and course access rights. Without well-thought-out synchronization, a student pays for a course but does not get access, and this is the first thing that breaks as the school grows.
An external learning system is justified when the methodology is already fine-tuned in another platform and migrating it is expensive. In that case, the website is responsible for acquisition and payment, while lessons, tests, and progress remain in the external circuit.
The key risk is desynchronization: access closes with a delay, progress is not pulled in, and support handles identical requests manually.
The choice is made not by the "trendiness" of the platform, but by where the school's bottleneck is: in launching, in showcase flexibility, or in methodology. Next, we break down how each option addresses typical failures.
How implementation works: stages of engineering work
Implementation begins with an audit of the school's current website: we look at the structure of the course catalog, how student and teacher dashboards are organized, where webinar recordings are stored, and how access is currently granted.
At this same stage we identify bottlenecks — usually these are manual access granting after payment and scattered databases across cohorts. The result of this step is a map of the current state with a list of growth points.
Seven steps of work
- Audit of the school's website. We analyze the existing sections, the student and teacher scenarios, and the current integrations with payment systems and email campaigns. We record what we transfer without changes and what we rebuild.
- Data schema. We design the structure of courses, cohorts, lessons, assignments, and student progress. We determine which entities live in Bitrix and which remain in 1C — so as not to duplicate data and not create desynchronization.
- Prototype of key scenarios. We assemble the path from payment to access being opened and the teacher's path to grading an assignment. The prototype shows where the logic breaks — fixes here cost less than after launch.
- Setting up integrations. We connect the website to 1C for students, payments, and enrollments, connect the payment gateway, email campaigns, and the webinar platform. We close each integration with error handling and retries so that a failure of one service doesn't bring down access granting.
- Testing under load. We run through cohort launch scenarios: mass payment, simultaneous student logins, lesson opening on schedule. We observe how access granting and data exchange with 1C behave when there are many times more requests than usual.
- Data transfer and migration. We transfer students, payment history, and progress across courses, and reconcile amounts and statuses before and after. We keep the old website available until we confirm that the new one returns correct data.
- Project handover. We give the client's team access credentials, the update policy, and instructions for typical operations — launching a cohort, refunding a payment, manually granting access. Plus a support level agreement and an escalation procedure.
After handover, we stay in touch according to the agreed policy: we make changes to access logic and integrations through a test environment so that changes don't affect the running student cohort.
What the client receives after launch
After the online school launches, the client receives not only a working portal but also a complete set of artifacts that the team can use to maintain and develop it without us.
This is a fundamental position: the system must be transparent and transferable, not a "black box" where any change requires calling a developer.
- Configured portal settings: the structure of the course catalog, page templates, lesson publishing rules, and settings for the student's personal account and the instructor's account.
- Integration diagrams: how the portal exchanges data with the accounting system, payment module, mailing service, and webinar system — indicating exchange points and the direction of data flows.
- Access policies: role separation (student, instructor, curator, administrator, methodologist) and the rules defining what each role can see and change.
- Access provisioning regulations: a step-by-step procedure for how a new employee is onboarded, and how rights are granted and revoked upon termination or a role change.
- Administrator documentation: instructions for routine operations — publishing a course, enrolling a group, handling requests, exporting reports.
- Backup and recovery description: what is backed up, at what frequency, and how to restore the portal from a backup in the event of a failure.
- Dependency and contact map: which external services are involved and whom to contact if any of them fails.
Such a set eliminates the main maintenance risk — dependence on a specific contractor.
A new administrator or vendor figures out the system from the documentation rather than by trial and error, and changes to rights and integrations follow the regulations rather than being done "by eye." Describe your task — we will come back with an estimate and a plan for what will be included in the handover in your specific case.
Case study: how the school's portal was rebuilt and what changed
The online school's portal on 1C-Bitrix previously relied on manual access provisioning: after payment, a manager matched the payment with the request and opened the course manually.
At the start of a cohort, when hundreds of requests came in per hour, access arrived with a delay, and some students left before receiving it. Support was drowning in identical requests like "I paid, but there's no access."
What was changed
Payment, the personal account, and the learning platform were linked into a single flow: once a payment is confirmed, access opens automatically, without a manager's involvement. Queue enrollment for a cohort and notifications at every step were added.
Load at the start was also separated out: the personal account and access provisioning no longer depend on spikes on the course catalog.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Access provisioning after payment | up to several hours, manually | automatically, minutes |
| Share of manual operations during enrollment | high, every student | isolated cases |
| Support requests about access | the main flow | decreased severalfold |
| Cohort start during peak enrollment | delays, manual handling | runs without manual intervention |
Manual labor during enrollment has almost disappeared, and support now handles substantive questions instead of sorting out payments.
The cohort start is no longer a scramble: the system handles the enrollment peak, access is granted immediately, and the school's team doesn't spend the first days on manual reconciliation.
How is a website on 1C-Bitrix different from a portal on Bitrix24?
1C-Bitrix and Bitrix24 are products from the same vendor, but they solve opposite tasks.
A school's public website is a storefront and a point of sales: a course catalog, program cards, landing pages for launches, enrollment forms, payment, and a student account with access to materials.
Bitrix24 is the internal contour: work chats, tasks, the sales department funnel, a database of students and leads, automation of reminders and repeat sales.
Mixing them in a single contour means either overloading the public part with unnecessary things, or exposing outward what should remain inside.
The key difference lies in the access model and the load. A public website handles anonymous and semi-anonymous traffic: search engine robots, ad clicks, registrations, and peak waves during launches.
What matters here is page delivery speed, correct indexing of the course catalog, and resilience to a surge of requests.
The internal portal serves a limited circle of employees and instructors, and its priority is access rights, action history, and data connectivity between departments.
The student database lives in two planes. On the website, it's a profile with progress, payments, and access to courses. In the portal, it's a client card with a history of touchpoints, curator tasks, and deals.
Data is not duplicated blindly: it is synchronized so that the manager sees the current status, while the student sees only their own.
A break in this connection produces the classic pain: the payment went through, but access didn't open, or the curator doesn't see that the person has already bought a second course.
Hence the practical conclusion for an online school: a public website on 1C-Bitrix covers sales and learning, while Bitrix24 covers operations and retention.
We design both contours so that they work as a single system: a request from the website enters the funnel, the payment status returns to the student account, and the student database remains unified.
Describe your learning model — we'll get back to you with an assessment and a plan for separating the contours.
Technical doubts before project start
Before the start, it almost always turns out that part of the system already exists: a portal on «1C-Bitrix», a student database in spreadsheets, payments in 1С.
That is why the first conversation is not about design, but about what we migrate, what we keep, and how not to lose it along the way.
We already have a portal deployed — will it have to be rewritten from scratch?
No. First comes an audit: we look at the information block structure, templates, custom components, modules, and what is actually in use.
The working core and accumulated content stay; we rewrite only what hinders growth — usually custom modules without documentation and templates with "quick and dirty" edits.
This approach is cheaper than a full replacement and does not wipe out the effort already invested in the portal.
How are students, groups, and learning history migrated?
We migrate data from the existing database: profiles, group assignments, course progress, payment history. We verify the schema before export — which fields are required, where duplicates are, how a student and course access are linked.
The migration runs on a copy; we reconcile the record count and spot-check accesses, and only then switch over the production environment. The student keeps their login and current progress.
What about 1С integration and access protection?
We set up the exchange with 1С on a schedule: contractors, contracts, payments, and statuses are pulled into the portal, while enrollments and course accesses are sent back.
We separate accesses by roles — student, teacher, curator, administrator — with a login log and two-factor verification for staff. This closes both material leaks and disputed situations like "paid but no access".
If your project has its own specifics — describe the task, and we will come back with an estimate and a migration plan.
Let's discuss the task and come back with an estimate and a plan
To come back with an estimate and a plan, we need a minimum of input — not a finished technical specification, but the context of the task.
Describe what already exists: the current platform or its absence, the course catalog and lesson structure, how you currently accept payments and grant access, which integrations are critical (payments, email campaigns, webinars, CRM).
If the site exists — provide a link and access to analytics: student behavior and drop-off points show what to fix first and what to design from scratch.
From there we work as follows:
- we analyze the input and define the project goals in measurable terms — course completion rate, conversion from lead to payment, support workload;
- we build a map of user scenarios: course selection, checkout, access to materials, progress, repeat purchases;
- we compare it against the current architecture and determine what we reuse and what we rewrite;
- we prepare a technical specification with the scope of work, stages, and acceptance criteria;
- we agree on the work plan, the deployment order, and the points where you see an intermediate result;
- we fix the areas of responsibility and the procedure for handing over access so that the project start doesn't stall on approvals;
- after approval, we launch the first stage and keep you informed at every step.
The estimate is based on the scope and complexity of integrations, not on the "average price of an online school website." So the more specific the input, the more accurate the timeline and the fewer revisions at the start.
Describe the task in any convenient form — we'll come back with an estimate, a work plan, and a proposal for the team composition.