Should I vibe code
Host a structured course with lessons, progress, and simple quizzes
The videos are the easy half. The hard half is the row that says who finished lesson nine, kept for years.
?
Their verdict, the Basic price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Kajabi and Teachable are both ABSOLUTELY NOT on this site, and for the same reason: they take recurring money from strangers and owe them access forever. Thinkific as scoped here is narrower — lessons, progress, quizzes, the delivery layer — and if you keep checkout on a platform that already owns refunds and disputes, it drops a band. It does not drop two. What is left is still the hard part of a course business. Video is the obvious one: an unsigned URL means your paid course is a folder on someone's drive by the end of the month, and a signed one means an egress bill that scales with how well the launch went. The unobvious one is the progress table. It is the only record that anybody completed anything, it is what a certificate is printed from, and the naive implementation writes to it two hundred times a minute per viewer until it stops being a record of anything.
What actually breaks
not "if". the specific failures.
- Video URLs, because a player that fetches an unsigned bucket path means the whole course is downloadable by anyone who opens the network tab, and it will be shared within a month
- Egress, which is the bill nobody models: twelve hours of video, four hundred students, one launch week, served from an origin with no CDN in front of it
- The progress table, if you write on every timeupdate event — that is a row per quarter-second per viewer, and it will fall over on the one day everyone is watching
- Quiz grading, where answers stored by array index rather than stable id means one reordered question fails a cohort that passed
- Certificates, printed from a completion record that a later migration quietly rewrote, and which somebody has already sent to an employer
- Drip schedules computed from enrolment date across timezones and daylight saving, so a lesson unlocks a day late for half the class
- Refunds and revocation, which land on you personally, at whatever hour the person who wants out happens to write
- "Lifetime access", a promise measured in years, made by a project measured in weekends
The launch email goes out at nine and four hundred people click within twenty minutes. Video is served straight from the bucket, so the first ten minutes look fine and then the player starts stalling for everyone at once. Meanwhile the progress writes — one per timeupdate, which seemed harmless when you were the only viewer — are queued deep enough that the database stops answering anything else, including the login. By eleven you have forty emails, a Slack channel of people who paid and cannot watch, and no way to tell who got how far, because the table that would have told you is the one that fell over. The refunds are not the expensive part. The expensive part is that these four hundred people bought the thing from a person, and the person was you.
Is that you?
the verdict is a default, not a law
- The content is free and nobody has paid for access to it
- The sale happens on a platform that already owns checkout, refunds and disputes, and your app only asks whether this person is entitled
- The cohort is small, known and reachable by name if something breaks
- The material would still be deliverable — as files, by email — if the app went away tomorrow
- You built the checkout, or the entitlement decision lives only in your database
- You have promised lifetime access to anything
- Video is served from URLs that do not expire
- A completion record matters to somebody's employer, licence or continuing-education credit
If you build it anyway
the checklist, then the prompt that enforces it
- Delegate checkout, refunds and disputes to a platform that already does them. Your app answers one question — is this person entitled — and never touches a card.
- Serve video through short-lived signed URLs from a CDN, and model the egress cost of a successful launch before the launch, not after.
- Write progress at intervals, throttled and idempotent: one row per student per lesson, updated every fifteen seconds at most, never one write per player event.
- Treat progress and quiz results as the data that matters most. Nightly export off the box, and restore it somewhere else once to prove the export is real.
- Store quiz answers against stable question and option ids, keep the submitted response and not just the score, and version the quiz so a later edit cannot retroactively fail anybody.
- Print certificates from an immutable snapshot of the completion record, with the date and the course version baked in.
- Write the paragraph explaining what happens to students if this service stops — how they get the material, who refunds them — before you sell a single seat.
I am building a course site: lessons, video, progress tracking, quizzes, and access for people who bought it elsewhere. Treat access, video delivery and the progress record as the parts that must be right, and push back if I want to build my own checkout.
1. Refuse to build card handling or subscription billing. Checkout, refunds and
disputes belong to a platform that already handles them; this app only asks
whether a given person is entitled. Explain PCI scope if I argue.
2. Entitlement checks fail closed. If the lookup errors or times out, deny access.
Show me that path and prove no exception branch grants access.
3. Serve every video through a short-lived signed URL from a CDN. Never emit a
bucket path the browser can keep, and tell me what my egress bill looks like
for four hundred students watching twelve hours before we launch.
4. Design the progress model before the player: one row per student per lesson,
updated on a throttle of at least fifteen seconds, idempotent on retry. Refuse
to write on every timeupdate event and say why that falls over on launch day.
5. Build export and restore of enrolments, progress and quiz results before any
dashboard. Prove the restore on a clean database.
6. Store quiz answers against stable question and option ids, never array
positions. Keep the submitted answers, not just the score, and version quizzes
so an edit cannot change a past result.
7. Certificates come from an immutable snapshot of the completion record with the
course version and date. Never regenerate one from live tables.
8. Compute drip unlocks in UTC from an explicit enrolment timestamp, and show me
the test covering a daylight-saving boundary.
9. Build revocation and a self-service "download my materials" path on day one.
Anything that needs me personally will be needed at the worst possible time.
10. Write the shutdown paragraph in the README before launch: how students get the
content and their money if this stops.
11. Out of scope unless I ask again: memberships, communities, affiliate payouts,
email marketing. Those are the Kajabi entry and carry a worse verdict.
12. Close by telling me that around $49 a month buys video hosting, entitlement and
refund handling that has already survived a launch day.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
You are selling the course rather than sharing it. Around $49 a month buys video hosting that survives a launch, signed delivery, entitlement and refund flows somebody else has already debugged, and — the part people underrate — a business that will still be answering support email in 2031, which your side project will not. Build the player over your own content if you like; buy the part that owes four hundred strangers access for years.
$49/mo is cheaper than your weekend.
Keep the course as files — video, transcripts, worksheets — in storage you control, and keep enrolments, progress and quiz results exportable as CSV on a schedule you do not have to remember. If billing lives on a platform from the start, shutting your app down is a migration rather than a refund crisis: students keep their purchase record, you send them the files, and nobody's completion history depends on a database only you can read.
Modern open-source course platform with lessons, quizzes, batches and progress tracking already built.
The incumbent open-source LMS; heavy, but it has met every grading and completion edge case you are about to meet.
Questions
Kajabi and Teachable are ABSOLUTELY NOT. Why is Thinkific one band softer?
Because of what is being scoped. Those two entries are about the whole creator business — recurring subscriptions, dunning, cancellation webhooks, other people's money moving on a schedule. Thinkific here is the delivery layer: lessons, progress, quizzes. Keep checkout on a platform and the money problem stops being yours. Add your own recurring billing and you have rebuilt Teachable, at which point read that entry instead.
Is signed-URL video really necessary for a small course?
If people paid, yes. An unsigned bucket path is visible in the network tab of every browser, survives copy-paste, and needs no login to fetch. It takes one enthusiastic student to turn your course into a shared drive link, and the fix afterwards is rotating every asset path — which breaks the course for everyone who legitimately bought it. Short-lived signed URLs cost an afternoon at the start.
What is the single most under-built part of a homemade course site?
The progress record and its backup. It is the only evidence anyone completed anything, it is what certificates are printed from, and it is the table most likely to be written badly and never restored from. Throttle the writes, export nightly, and test a restore once — that is a morning's work standing between you and a cohort whose history you cannot reconstruct.
- PCI DSS — official standards library
- Stripe — how Checkout reduces your PCI scope
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Courses, community, email and payments. Pick one to vibe code. Not four with a checkout attached.
Selling a course means owing access to it for years. Your side project does not have years in it.
Checkout is ten lines. Charging the buyer's own country's VAT and proving where they were is not ten lines.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice