The pitch for most teaching software is that it saves time. Then you open it and discover the time it saves is yours to spend re-entering the same material into a slightly different box. We started EdTechCore because a language school we know was running four tools at once — a whiteboard, a document folder, a messaging app for homework, and a spreadsheet that decided who had paid. Four tools, four bills, and four places where the truth could quietly disagree with itself.
The board came first, because a lesson is a live thing and it needs a live surface. But the part teachers actually asked about, over and over, was smaller and less glamorous: the tasks. Who makes them. How long that takes. And who marks them at eleven at night.
The evening nobody mentions in the brochure
A teacher plans a lesson in about twenty minutes. Then comes the other work. Twelve gap-fill sentences typed into a document. A matching exercise laid out by hand so the columns line up. A multiple-choice set where the distractors have to be wrong in an interesting way rather than obviously wrong. Then the lesson happens, and afterwards the same twelve sentences come back — twelve times over, once per student — and somebody has to read all of them and put a number at the bottom.
None of that is teaching. It is formatting and arithmetic wearing a teacher’s clothes. And it scales in exactly the wrong direction: the better the school does, the more of it there is.
A full timetable should not cost you your evenings. If the software cannot take the formatting and the arithmetic, it has not earned the subscription.
What a task actually is
Before the constructor made sense, the structure underneath it had to. In EdTechCore a course is not a folder of files — it is four nested things, and every one of them is addressable:
- Course — the whole thing a group is working through.
- Module — a coherent chunk of it.
- Lesson — what happens on the board on a given day.
- Task — the smallest unit that a student can answer and a machine can check.
That last line is the load-bearing one. A task is defined as something with a checkable answer, which means the system can be honest about which tasks it can mark and which it cannot. Nothing pretends. A gap-fill has a right answer; the engine owns it. A written paragraph does not; that one comes to you.
Three ways to fill a lesson
The constructor is the screen where a lesson stops being empty. There are three routes through it, and they are meant to be mixed inside a single lesson rather than chosen once and lived with.
1. Write it yourself
Pick a task type, type the content, done. No document, no formatting, no exporting a PDF that immediately becomes the version nobody has. The task type carries its own layout, so a matching exercise looks like a matching exercise without anyone dragging a table around at midnight. This is the fastest path when you know exactly what you want, which for an experienced teacher is most of the time.
2. Let AI draft a batch
Give it the topic and the level and ask for ten. You get ten drafts, in the right task type, in seconds — and then you do the part that actually needs you: read them, delete the three that are boring, fix the one where the distractor is accidentally also correct, and keep the rest. Drafting was never the hard part of teaching. It was just the slow part.
3. Pull from the library
The task you wrote in March is still yours in September. Tasks live in a library, not inside the one lesson they were born in, so they can be reused across courses without being copied. This is the compounding one: the first month in the constructor is roughly as fast as what you did before, and the sixth month is not remotely close, because by then most of a lesson is assembled from work you have already done and already trust.
Why reuse beats generation
A generated task is new every time and has to be checked every time. A library task was checked once, survived a real classroom, and can be dropped in with no review at all. The library is the feature that actually gives you the evening back.
The rule we will not break
There is one line in the product that is not up for negotiation, and it is worth stating plainly because plenty of tools in this category are quietly on the other side of it:
AI helps you draft tasks. It never decides a mark.
Marking is done by a deterministic engine. Given the same answer it returns the same result, today and in a year, for every student in every class. It is instant for the student, it costs nothing to run, and — the part that matters when a parent asks — it can be explained. A grade that came out of a language model is a grade that cannot be defended in a conversation, and a school that cannot defend its grades has a problem no feature list fixes.
So the division of labour is deliberate: AI drafts, the engine marks, the teacher decides. Everything the engine can mark, it marks. Everything it cannot — the writing, the judgement calls, the answer that is technically wrong but interestingly wrong — is routed to a human, which is the only place it belonged in the first place.
What it changes during the lesson
A task built in the constructor is not a worksheet. It goes straight onto the course canvas, which is the same board the class is looking at in real time, so answers come back while the lesson is still happening rather than the following week.
The board shows those live answers as aggregates — how the class is doing, where the room is stuck — and never as individual names. The class can see its own progress; no student gets exposed to the room. That distinction sounds small on a feature list and is enormous in an actual classroom of teenagers.
Teachers also get a publish step, which exists because rehearsing on a live board in front of students is a bad time. You edit a draft, publish when the students should see it, and reset back to the published version whenever an experiment goes sideways. Ink drawn over the top during the lesson is momentary and never saved.
And then the books close themselves
This is the part that surprises people, because it is two departments away from a gap-fill exercise. The lesson a task belongs to is on a schedule. That schedule is what the school bills against. So plans, invoices, payments and access windows post to a real double-entry ledger as they happen, in the school’s own currency.
The month does not get closed by reconstructing it from memory and a spreadsheet at the end. It closes from what actually took place. The constructor is where that chain starts: a task, in a lesson, on a schedule, on the books.
What it is not
Two honest caveats, because a page that only lists strengths is an advertisement rather than an explanation.
- It is not a marketplace. There is no store of ten thousand pre-made courses to browse. The library that matters is the one your school builds, which is slower to start and considerably better six months in.
- It is not open to everyone yet. EdTechCore is invitation-only while we launch. Teachers get in through their school or after a demo; students get in through a link or a short code from their teacher.
Want to see it on your own material?
The fastest way to judge any of this is to watch someone build a lesson out of your content rather than a demo dataset. That is what the demo is.
Where this goes next
More task types, and a better answer to the question of what happens when a student is wrong in a way the engine can recognise but not yet explain. I am filming the whole build as it goes — the short version lands on TikTok, the long walkthrough on YouTube, and whatever I get wrong in between ends up on both.
If you run a school and any of the evening above sounded familiar, that is the entire reason this exists.