Education and consulting
Build your own course platform instead of renting one
Our client program runs on software we built ourselves, at code.eclipta.one. Content, member access, progress and billing sit in one system we control. The same build is available for your business.
What renting a course platform actually costs you
A rented course platform is cheap on day one and expensive on day four hundred. The monthly fee is rarely the problem. The problem is that your program, your participants and your revenue now live inside a product that was designed for the average customer, and you are not the average customer.
The visible symptoms are small at first. A module should unlock when someone finishes the previous one, but the platform only supports a date. A participant stalls for two weeks and nobody finds out, because the reporting shows completion percentages and not the person who stopped. Somebody on your team spends an hour every Monday granting access by hand, because the payment tool and the course tool do not talk to each other properly.
The invisible cost is the one that matters. Your lesson videos, your worksheets, your participant list and your access rules are stored in a shape that only that vendor can read. Pricing moves to per seat as you grow. A feature you need sits one tier up, or does not exist and never will. You are running a program you designed on rails somebody else laid.
- Access gets granted by hand every time somebody joins or upgrades.
- You can see that a module has a low completion rate, but not why.
- Modules unlock on a calendar date instead of on finished work.
- Payments, dunning and cancellations live in a different tool than the content.
- Per seat pricing turns a good cohort into a bigger bill.
- Exporting your program means exporting a folder of videos and nothing else.
How an owned client program platform works
We built ours because we needed it, then kept it, because the arguments for owning it got stronger rather than weaker. This is what it does.
- 01
The program is the structure, not a video list
Modules and lessons, each lesson with the result the participant can show afterwards and the step it depends on. That structure is what everything else hangs from: unlocking, progress, coaching, reporting.
- 02
Access opens on completion, not on a date
Somebody finishes module three, module four opens. No admin, no scheduled email, no spreadsheet of who is allowed to see what. Payment status, cohort and progress decide access together, in one place.
- 03
It watches where people stop, at the minute
Not a completion percentage per module. The actual point in the actual lesson where people drop out. When seventeen of twenty eight participants leave the same lesson at minute eleven, that is a fact about the lesson, not about the participants. You fix the lesson.
- 04
Stalled participants surface as people, not as numbers
A participant who has not moved for seven days gets a nudge. If nothing changes, they land on a coach's list with the context attached. The system handles the reminder. It does not handle the conversation.
- 05
Billing runs in the same system as the content
Invoices, dunning, upgrades and cancellations against the same participant record that holds progress and access. One source of truth means access and payment can never quietly disagree.
- 06
It stops instead of guessing
Anything unambiguous runs on its own. Anything ambiguous waits for a person. Anything touching money or a promise to a participant goes to a person by default. A refund, an exception, an early unlock: those are decisions, and decisions stay human.
Take this with you
A free prompt: turn a described program into a real curriculum
Before anyone builds a platform, the program has to hold up. This prompt does that one job. You describe your program the way you would describe it out loud, in any state of mess. It returns a module and lesson structure where every lesson names the one result the participant can show afterwards, the prerequisite that has to be in place before it, and the point where people realistically drop out. It ends with a short, honest list of what to rent and what to own.
You are a curriculum architect for paid client programs run by
consultants, agencies and coaches. You design programs that people
actually finish, not programs that look impressive on a sales page.
I will describe my program below in loose, unstructured language.
It may be a rough idea, a list of topics, or an existing course
that is not working.
YOUR TASK
Return a module and lesson structure. For EVERY lesson, give exactly
these four lines:
LESSON: short working title
RESULT: the one concrete thing the participant can show, send or
run after this lesson. A noun, not a feeling. "A written
one page process description", not "understands processes".
REQUIRES: what must already exist before this lesson can work.
Name the earlier lesson, or write [EXTERNAL: ...] if it is
something they must bring from outside the program.
DROP-OFF RISK: the specific point where people realistically stop.
Name the moment, not the mood. "The first time they have to
open their own numbers", not "loses motivation".
RULES
1. If a lesson has no showable RESULT, it is not a lesson. Merge it
into a neighbouring one or move it to reference material, and say
which you did and why.
2. Order lessons by dependency, never by topic tidiness. If lesson 4
requires something produced in lesson 6, say so and reorder.
3. Six lessons per module maximum. If a module needs more, it is two
modules.
4. Flag every lesson where the RESULT depends on the participant
having done work outside the program. Those are where cohorts
split into finishers and non-finishers.
5. Do not invent content I did not describe. If a module clearly has
a hole, write [GAP: ...] and name what is missing.
AFTER THE STRUCTURE
Give three short lists:
A. THE THREE HARDEST DROP-OFF POINTS in the whole program, in
order, with one concrete change that would reduce each.
B. WHAT TO RENT, the parts of running this program where standard
software is genuinely good enough.
C. WHAT TO OWN, and why: the content itself, the participant data,
and the access rules. For each one, name what you lose if it
lives in somebody else's system.
MY PROGRAM:
[DESCRIBE IT HOWEVER YOU WOULD SAY IT OUT LOUD. TOPICS, LENGTH,
WHO IT IS FOR, WHAT THEY SHOULD BE ABLE TO DO AT THE END. MESSY
IS FINE. INCLUDE WHAT IS ALREADY BUILT, IF ANYTHING.]- Paste the prompt into a capable chat assistant and describe your program where marked. Do not tidy it up first.
- Read list A before you read the structure. The drop-off points tell you which lessons are worth rebuilding.
- Check every RESULT line. If you cannot picture the participant showing you that thing, the lesson is still a topic.
- Run it a second time with the corrected description. The second structure is usually the usable one.
- Keep list C next to your platform contract when the renewal comes up.
The result is a structure on paper. That is genuinely useful and it is also where it stops. It delivers nothing to anyone. It does not manage access, so somebody still opens modules by hand. It cannot see where participants actually stop, because it has never watched one, so the drop-off points are informed guesses rather than measurements. It does not invoice, chase or cancel. And the moment that structure gets typed into a rented platform, it stops being yours in any practical sense: the content, the participant list and the access rules sit in a shape only that vendor can read.
From a curriculum on paper to a platform you own
The prompt designs the program. The platform runs it, in front of real participants, without somebody doing admin every Monday. The distance between those two is where every real client program either works or quietly leaks people.
The difference shows up clearest in what you can find out. A structure on paper tells you where people probably drop out. A system you own tells you that seventeen of twenty eight left the same lesson at the same minute, which turns a guess into a repair job you can finish this week.
It also shows up in ownership. We run our own program on our own software for a plain reason: the content, the participant data and the access rules are the business. Renting the delivery of your best asset is a decision worth making on purpose rather than by default.
None of it runs blind. Unlocks, nudges, invoices and reminders happen on their own because the rules are unambiguous. Refunds, exceptions and anything that changes what a participant was promised go to a person, every time.
- Content, member access, progress and billing in one system, on your infrastructure.
- Access that opens on finished work instead of on a calendar date.
- Drop-off visible at the minute, per lesson, so you can fix the lesson.
- Stalled participants nudged automatically, then handed to a coach with context.
- Invoices, dunning and cancellations against the same participant record.
- No per seat pricing and no feature tier standing between you and a change.
- Your program exports as structure and data, not as a folder of video files.
Frequently asked questions
Should I build my own course platform or use Kajabi or Teachable?
If you are validating a first program, rent. The monthly fee buys you speed and you should spend that time on the content instead. The calculation changes once the program is proven and recurring: when access rules are being applied by hand, when per seat pricing scales with your success, or when a change you need is not on the vendor's roadmap. At that point the platform is shaping your program rather than serving it.
Can I not just do this with ChatGPT and a Google Drive folder?
You can design the curriculum that way, and the prompt on this page is exactly that. What you cannot do is deliver it. A chat assistant does not open module four when somebody finishes module three, does not notice that a participant has not logged in for a week, does not send an invoice and does not know that one participant paused their payments. Those are the parts that consume a person's week, and they are the parts a system takes over.
Who owns my course content and my participant data on a rented platform?
You own the copyright in your content, and that is not the interesting question. The interesting question is what you can take with you. On most platforms you can export videos and a list of email addresses. Progress, completion history, access rules and the structure of the program itself typically come out in a form nothing else can use, or not at all. Owning the system means the data stays in a normal database on infrastructure you control.
What does it cost to build a client program platform?
There is no list price, because nothing is being resold. Scope decides it: how many programs, whether cohorts run in parallel, how billing works, what has to migrate from an existing tool. The honest comparison is against your current subscription over several years plus the hours spent on manual access and reporting today. We scope it first and tell you the real number before anything gets built.
How long does it take to move an existing program off a course platform?
The content moves quickly, because videos and documents are just files. The work sits in the rules: who gets access to what, on which condition, at which price, and what happens on cancellation. Those are usually spread across two or three tools and somebody's head. Writing them down is most of the project, and it is worth doing even if you decide against building.
Can it tell me why people drop out of my course?
It can tell you where, precisely, which is the part nobody has. Per lesson, at the minute, across the cohort. When the same timestamp appears for most participants in one lesson, the lesson is the problem. Why they left is still your judgement call, but you are making it about one specific eleven minute mark rather than about a module with a low completion percentage.
Does the system decide anything about participants on its own?
Only the unambiguous parts. Unlocking the next module when the previous one is finished, sending a nudge after seven days of no activity, issuing the invoice that was agreed. Refunds, exceptions, early access and anything that changes what a participant was promised go to a person. The rule is the same across everything we build: automatic where it is clear, human where it is not, always human where money is involved.
Bring us your program
The useful starting point is the program you are already running, including the parts that annoy you. Show us how access gets granted today, where participants stall, and what your current platform will not let you change. We will tell you honestly which parts are worth owning, which are fine rented, and what building it would take. If renting is still the right answer for you, we will say so.
Apply