What this post covers
- How this project started from real inconveniences in my tablet-based classes
- Why existing learning platforms felt insufficient
- What I wanted to implement first in
AirClass
This first post explains why I began planning this project and what direction I wanted to take for the first implementation.
It started from the limits of tablet-based teaching, not only its advantages
I teach with a tablet. Tablet-based lessons have clear advantages. I can explain directly on the same material students are seeing, move between problems and notes in the same context, and avoid the feeling that paper handouts and screen materials are disconnected.
But as I kept teaching this way, I also saw clear limits. The first problem was students who needed more time to follow along. The class moves forward, but some students want to see the previous screen or hear the previous explanation again. Once the teacher moves on, it becomes hard for them to recover that moment.
In a classroom, that gap is larger than it looks. A natural flow for fast students can feel like a break in continuity for slower students. So my first concern was not flashy technology. It was a simple question.
Can I keep the advantage of teaching from a shared screen while making sure slower students do not immediately lose the thread?
That question became the starting point of AirClass.
The second problem was the limits of existing platforms
I often used interactive learning tools such as Desmos and Kahoot!. They are well-made services and can quickly make a class more interactive.
But after using them for a while, two limits became more noticeable.
The first was paid plans and service changes. A feature I had become used to could move into a paid tier, or a service redesign could make it harder to reuse the lesson patterns I had built before.
The second was more fundamental. If the platform does not have the function I need, I simply cannot do it. Every class is a little different, and every teacher has a different flow in mind. But an external platform naturally limits the teacher to the functions and screens defined by that company. In the end, the teacher uses the platform, but can also become trapped inside its limits.
That point stayed with me. The center of a class should be the teacher's intention and students' responses. But sometimes the class began to feel like something that had to fit inside the range allowed by the platform.
I also kept asking, "Does it really have to be web-based?"
I also had doubts. Did a classroom tool really need to be a web app? Would using the browser add unnecessary complexity? I did not assume from the beginning that the web was the answer.
However, while watching the rise of AI digital textbooks and other AI-based education tools, something became clearer. Many digital tools entering schools eventually became tied to cost, product policy, and pricing. The better the feature, the more strongly it tended to be locked inside a product plan.
At the same time, working at Busan Software Meister High School exposed me every day to web development, service architecture, and AI application skills. That changed my perspective. There were already many excellent open-source tools, and tools such as OpenCode, local LLM models, and agent-based development environments were becoming easier for teachers to combine and use directly.
So the question changed.
Could a teacher build and improve the classroom tools they actually need faster by using AI and open source?
From that point, AirClass became less like a plan to build one teaching app and more like a personal open-source project where a teacher builds the tools needed for their own class, studies the problems that appear, and improves them.
So I decided to build it myself
After reaching this point, adapting to existing platforms as much as possible no longer felt sufficient. I knew best which functions were needed in my class, but the authority to implement them was outside my hands.
So I changed direction. Instead of waiting for a finished product, I decided to build what I needed, try it in class, and fix what did not work. At first it seemed like a small helper tool, but as I built it, I realized that it touched the entire lesson flow.
Students needed a way to keep up with the same screen without losing the thread. Teachers needed a tool where presenting materials, giving questions, collecting responses, giving feedback, and keeping records could connect in one flow. Implementing those needs one by one led to what is now AirClass.
What I wanted to implement first
At the time of this first post, I was not trying to build a huge integrated platform. I wanted to begin with the part my own class needed most and test it as a small prototype.
1. Keep the advantage of shared-screen teaching, but let students revisit previous content
The first goal was to stop the lesson screen from moving only forward. Even if the teacher continues around the current screen, students need at least a minimal way to check a previous moment again.
That means the student side should be able to:
- Recheck a recent slide, problem, or material
- Keep the context between the current explanation and the previous one
- Avoid being completely cut off when they fall behind
2. Build interactive classroom tools that are not locked to external platforms
The second goal was to build tools where I could directly add the flow I wanted. When I wanted to use quizzes, short responses, or interactive elements, I had to stop if the existing platform did not support the exact behavior.
This does not mean rebuilding everything from scratch. But the core flows I use repeatedly should not be too vulnerable to external service policy changes.
3. Use AI and open source so teachers can handle their tools more directly
The third goal was to use AI not only as a product to consume, but as a way to build classroom tools. Open-source tools, local models, and agent-based development tools have become much more accessible. I felt that teachers now have an environment where they can implement and test needed functions much more directly than before.
So AirClass is not just an education service with AI features. It is also an experiment in helping a teacher build and revise their own classroom tools more directly.
Closing
AirClass did not begin as a grand platform name. It began as a series of small attempts to solve problems from tablet-based classes: how to help students who miss a moment, and how to move beyond the limits of existing platforms.
What remains is not to keep writing about the idea, but to build small pieces, try them in class, and confirm the structure that is actually needed. In the next post, I will write about how I planned the first prototype.
💬 댓글
이 글에 대한 의견을 남겨주세요