The Online Course Platform Development Guide: Build or Buy, and How to Handle Video and Payments
Putting courses online starts with a business question, not a technical one: where does the weight of this business actually sit?
If courses are an extension of your main business, running them on an existing platform is usually the rational choice. If courses are the main product, then revenue share, ownership of student data, and the brand experience get harder to ignore every year. To judge which side you are on, you first need to know how much a course platform really has to handle.
The core features of an online course platform
Video playback and course structure: organizing chapters and lessons, the player itself, playback speed and subtitles, resuming where the student left off. This is the part students feel most directly, and a mediocre experience translates straight into lower completion.
Progress tracking: where someone has reached, how much is complete, which chapter loses the most people. Progress data is not only for the student — it is your evidence for how the course content should change.
Quizzes and assignments: automatically marked multiple choice is relatively simple. Written answers or uploaded assignments involve a marking workflow and notifications, and the workload difference is substantial.
Certificates and completion criteria: how completion is defined, whether certificates need to be verifiable, and whether corporate buyers require learning-hours reports.
Payments and orders: single-course purchases, subscriptions, installments, discount codes, corporate bulk purchases, and issuing government-mandated uniform invoices (the standardized tax invoices required for sales in Taiwan). Each sales model is a separate piece of development work. For payment method selection and reconciliation, see Payment Gateway Integration in Taiwan.
Discussion and Q&A: course comments, a questions area, community links. This is often treated as a nice-to-have, but it is a significant driver of both completion rates and word of mouth.
Administration: publishing, scheduling, student management, refunds, reporting.
One practical reminder: the first version does not need all of it. Work out which features you cannot open a course without, and leave the rest for later. The same logic underpins A Guide to MVP Development.
Packaged platform or custom build: the differences that decide it
| Consideration | Packaged platform | Custom build |
|---|---|---|
| Time to go live | Very fast; configure and sell | Requires a design and development period |
| Cost structure | Revenue share or monthly fee, growing with sales | Higher up-front investment, then mostly operations |
| Student data | Some of it sits with the platform | Entirely in your own database |
| Brand experience | Limited by the platform’s templates and rules | Designed entirely around your brand |
| Integration | Depends on what the platform exposes | You can deliberately connect membership, e-commerce, and internal systems |
| Platform risk | You adapt when rules or rates change | You carry the operational responsibility yourself |
The important thing about revenue share is not the percentage — it is that it is a variable cost. The better your courses sell, the larger that line becomes, whereas building your own is a one-off investment. So the judgment is not a comparison of today’s numbers; it is whether course revenue is on a sustained growth path and whether this is a line of business you intend to run for the long term.
Data ownership is not just a matter of comfort, either. Learning behavior, completion patterns, and purchase history are the basis for designing your second course, running remarketing, and building a community. If you can see that data but not take it with you, there will always be a missing piece in your course planning.
There is also a middle path: use an existing platform to validate whether the course sells, then build your own once the catalog and revenue are stable, migrating the existing data across. The precondition is asking, at the point you choose the platform, exactly what can be exported.
Video protection and bandwidth: the part most underestimated in a custom build
Video is a course platform’s most expensive asset and the one most in need of protection.
On protection, the combination commonly used in practice is: streaming rather than offering the original file for download, playback links that expire and are tied to the logged-in identity, a moving watermark showing the student’s identifier, and a limit on simultaneous device logins. It is important to understand that the purpose of these measures is to raise the cost of leaking and make it traceable, not to make it impossible.
On cost, video spending on a custom build is driven by three factors:
- Total video length and quality: this determines storage volume and how much data each playback transfers
- Number of views: more students and more rewatching means higher bandwidth costs
- Where viewers are located: cross-region delivery is generally more expensive than serving within a region
Because bandwidth is a variable cost that scales with usage, successful enrollment actually pushes this expense up. That is not a bad thing, but when budgeting, treat it as an item that moves with revenue rather than as a fixed overhead.
What you can control: offer multiple quality levels so devices select automatically, reduce the retention tier for older courses, and move rarely watched content to cheaper storage.
Student data and privacy: handle it at the design stage
A course platform collects more sensitive information than people expect: names, contact details, payment information, learning behavior, and for corporate training, possibly employer and assessment results.
A few principles:
- Collect only the fields you genuinely need — if you are not sure what it is for, do not collect it
- Be specific about notice and consent, and separate marketing use from the use required to deliver the service
- Layer permissions: an instructor should see less student data than an administrator
- Set retention and deletion periods, and give students a route to access, correct, and delete their data
- Write outsourced processing into contracts — for example video providers and payment providers
For how to write the privacy policy and design cookie consent, see How to Write a Website Privacy Policy. If you want to lower the barrier to registration, third-party login is a common approach; the considerations are covered in Social Login and SSO.
What belongs in the first version, and what does not
Custom builds usually fail not because something could not be built, but because the first version tried to do everything.
Normally essential in version one: publishing courses and videos, students registering and signing in, taking payment and granting viewing access, playing reliably and remembering progress, and an admin view of who bought what. Without any one of these, you cannot run the course.
Normally deferrable:
- Complex question types and automatic marking
- Certificate generation and online verification
- Discussion forums and community features (an existing messaging group works early on)
- Subscriptions, installments, corporate bulk purchases, and other sales models
- A mobile app (get the web version right on phones first; most students start in a browser)
- Detailed learning analytics
The test is simple: ask whether the first cohort can still complete the course without this feature. If they can, leave it out for now.
Four common mistakes
- Building the app before the web version. App development and store submission cost noticeably more, and while student numbers are still unproven, getting the mobile web experience right is usually the better investment.
- Underestimating the admin side. If publishing, scheduling, refunds, and reissuing access are awkward, your operations staff will be going back to the engineers every day.
- Treating the video experience as a detail. Stuttering playback, progress that is not remembered, and having to start over on a different device are among the most direct reasons people ask for a refund.
- Not planning refunds and access revocation. How viewing access is canceled after a sale, and whether how much has already been watched matters, are rules to set before you start selling.
Beyond the platform: enrollment and word of mouth are the other half
Once the technology is finished, the course still has to sell. Courses are an experience good — you only know if it was worth it afterwards — so students and parents research reviews repeatedly before paying, and claims about learning outcomes have clear limits: you cannot guarantee grades, you cannot guarantee admission, and paid partnerships must be disclosed. The legitimate approaches and the lines you cannot cross are covered more fully in Word-of-Mouth Marketing for Cram Schools and Online Courses, and it is worth reading alongside your feature planning: the testimonials section on a course page, the timing of review requests after completion, and how the discussion area is run all affect later enrollment.
If student records need to connect to your membership data, see the Membership and CRM System Development Guide for the design approach. If courses are sold alongside physical products, the sales-side options are covered in Building an E-commerce Site.
The difficulty with an online course platform is not any single feature. It is that video, payments, learning records, and marketing data all have to join up into one continuous line. Work out where the weight of the business sits, and the technical choices start to have a basis.
If you are weighing an existing platform against building your own, or you want to move existing course data into a system you control, talk to NETVANA about your course plans — we clarify the feature scope and the cost structure before discussing an approach. For what each service includes and delivers, see the software services overview.
Further reading: for what belongs in the first version, see A Guide to MVP Development; for the limits on marketing claims when recruiting students, see Word-of-Mouth Marketing for Cram Schools and Online Courses; for making use of student data, see the Membership and CRM System Development Guide; and for payment and reconciliation, see Payment Gateway Integration in Taiwan.
