Micro-Learning App Development & Skill Exchange Platform | South Korea

5-Minute Learning, Peer-to-Peer Tutoring & Skill Trading Platform — South Korea

Project Overview

We developed a Micro-Learning & Gamified Skill Exchange mobile application for a South Korea-based education technology company that wanted to create a more interactive alternative to traditional online learning platforms.

The platform combines short-form learning, live peer-to-peer tutoring, gamification, progress tracking, and an internal skill-trading token economy. Instead of requiring users to purchase every learning session with traditional payments, the platform allows members to earn tokens by sharing their own skills and spend those tokens when learning from other users.

The application was designed around a simple concept:

Learn a skill → practice it → share your own skill → earn tokens → use tokens to learn from others.

The Android application was developed using Kotlin and Jetpack Compose, with ExoPlayer providing video playback and streaming capabilities. Real-time peer-to-peer tutoring was implemented using WebRTC, while the backend was developed using Elixir/Phoenix. PostgreSQL manages persistent application data and Redis supports caching, real-time state, and token-related operations.

The project combines:

Micro-Learning + Live Video Tutoring + Gamification + Skill Exchange + Token Economy

into a single learning ecosystem.

 

---

The Business Challenge

Traditional online learning platforms often require users to purchase courses, subscribe to memberships, or follow lengthy learning programs.

The client wanted to create a different learning model based on short lessons and peer-to-peer knowledge exchange.

The main challenges were:

• Long courses can discourage users from completing lessons.

• Learners often need practical interaction rather than passive video.

• Many users possess valuable skills they could teach to others.

• Traditional tutoring can be expensive.

• Learners need visible evidence of progress.

• Learning platforms often lack strong community-based incentives.

• Live tutoring requires reliable real-time communication.

The client therefore wanted a platform where learning could happen in short, focused sessions while users could simultaneously become teachers.

The core concept was:

User
 ↓
Learn 5-Minute Lesson
 ↓
Practice Skill
 ↓
Earn Progress
 ↓
Teach Another User
 ↓
Earn Tokens
 ↓
Spend Tokens on New Skills

---

Project Objectives

The platform was designed to:

1. Provide short, focused learning sessions.

2. Keep individual lessons around five minutes.

3. Support interactive video learning.

4. Allow users to discover different skills.

5. Enable peer-to-peer tutoring.

6. Provide real-time video calls.

7. Create an internal skill-trading token economy.

8. Reward users for teaching skills.

9. Allow users to spend earned tokens on tutoring.

10. Track learning progress.

11. Implement achievement badges.

12. Encourage repeat learning.

13. Provide a scalable real-time backend.

14. Maintain reliable video playback.

15. Create a modern Android learning experience.

---

The Solution

We developed a mobile-first learning ecosystem with four interconnected components:

                    USER
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
   MICRO-LESSONS   SKILL EXCHANGE   PROFILE
        │             │
        ▼             ▼
     EXOPLAYER      WEBRTC
        │             │
        ▼             ▼
     LEARNING       LIVE TUTORING
        │             │
        └──────┬──────┘
               ▼
          PROGRESS SYSTEM
               │
               ▼
           TOKEN SYSTEM
               │
               ▼
          GAMIFICATION
               │
               ▼
         BADGES / LEVELS

The system was designed so that learning, teaching, rewards, and community interaction reinforce each other.

---

Micro-Learning Model

The primary learning unit was a 5-minute interactive lesson.

Instead of asking users to commit to a one-hour lecture, the platform breaks learning into small, manageable sessions.

For example:

Photography
    ↓
Lesson 1 — Camera Basics
    ↓
5 Minutes

Lesson 2 — Exposure
    ↓
5 Minutes

Lesson 3 — Composition
    ↓
5 Minutes

This creates a learning path from multiple short lessons rather than one long course.

---

5-Minute Video Lessons

Each lesson can contain:

• Lesson title

• Video

• Short introduction

• Learning objectives

• Interactive elements

• Progress indicator

• Completion action

• Next lesson

The application was designed to make the learner's next action obvious.

---

ExoPlayer Video Streaming

ExoPlayer was used for Android video playback and streaming.

It provides capabilities needed for modern mobile video experiences, including:

• Video playback

• Streaming

• Playback controls

• Buffering management

• Seek functionality

• Full-screen playback

• Playback state handling

A typical learning flow is:

Lesson Selected
      ↓
Video Request
      ↓
ExoPlayer
      ↓
Buffer / Stream
      ↓
Video Playback
      ↓
Lesson Completion

---

Video Learning Experience

The lesson player was designed to keep the user focused on the learning content.

Typical interface:

┌─────────────────────────────┐
│                             │
│       VIDEO PLAYER          │
│                             │
│      04:12 / 05:00          │
│                             │
├─────────────────────────────┤
│ Lesson: Camera Basics       │
│                             │
│ [Complete Lesson]           │
└─────────────────────────────┘

The interface can also display learning progress and the user's current position in the lesson.

---

Lesson Progress Tracking

The system records learner progress.

Possible states include:

Not Started
     ↓
In Progress
     ↓
Completed

The backend can maintain progress for individual lessons and larger learning paths.

---

Learning Paths

Individual micro-lessons can be organized into structured skill paths.

For example:

UI Design Fundamentals

1. Design Principles
2. Color Theory
3. Typography
4. Layout
5. Components
6. Mobile UI
7. Final Challenge

Each lesson remains short while the overall learning path provides structure.

---

Skill Categories

The platform can support multiple categories.

Examples include:

• Programming

• Graphic Design

• Photography

• Languages

• Marketing

• Business

• Music

• Video Editing

• Communication

• Productivity

• Career Skills

• Creative Skills

The category structure can be expanded as the community grows.

---

Skill Discovery

Users can discover skills through:

• Categories

• Search

• Recommended lessons

• Trending skills

• Popular tutors

• Learning paths

• Personalized recommendations

The objective is to reduce the friction between deciding to learn something and actually starting a lesson.

---

Peer-to-Peer Skill Exchange

The defining feature of the platform is the ability for users to teach each other.

A user may be:

Learner in one skill

and

Tutor in another skill.

For example:

User A
Knows: Python
Wants to learn: Korean

User B
Knows: Korean
Wants to learn: Python

The platform allows their skills to become mutually useful.

---

Skill Exchange Economy

The platform uses an internal token-based economy.

The basic model is:

Teach
 ↓
Earn Tokens
 ↓
Save Tokens
 ↓
Find Tutor
 ↓
Spend Tokens
 ↓
Learn

Tokens represent participation within the platform rather than requiring every learning interaction to involve a separate monetary transaction.

---

Token Earning

Users can earn tokens through activities such as:

• Completing eligible teaching sessions

• Providing tutoring

• Completing platform challenges

• Achieving milestones

• Participating in approved community activities

The exact earning rules are controlled by the platform's business logic.

---

Token Spending

Users can spend their earned tokens to access peer tutoring.

For example:

User Balance
100 Tokens

Tutoring Session
25 Tokens

Remaining
75 Tokens

The backend validates the balance before allowing a token-based transaction.

---

Token Transaction Architecture

Token operations were designed to be server-controlled.

User Requests Session
       ↓
Check Token Balance
       ↓
Reserve / Deduct Tokens
       ↓
Create Tutoring Session
       ↓
Tutor Receives Allocation
       ↓
Transaction Recorded

This helps prevent clients from manipulating token balances locally.

---

Token Ledger

A transaction history can record:

• Transaction ID

• User

• Amount

• Transaction type

• Source

• Destination

• Timestamp

• Related tutoring session

Example:

+50 Tokens
Teaching Session

-25 Tokens
Tutoring Session

This provides transparency for users and administrators.

---

Redis for Token State

Redis was used for fast state management and caching where required.

It can support:

• Temporary token state

• Session state

• Locks

• Rate limiting

• Fast counters

• Real-time state

• Frequently accessed data

Persistent financial-like records should remain in PostgreSQL rather than relying solely on Redis.

---

PostgreSQL Database

PostgreSQL was used for persistent application data.

Potential entities include:

Users
Skills
Lessons
Courses
Lesson Progress
Tutors
Tutoring Sessions
Token Transactions
Badges
Achievements
User Profiles

A simplified relationship is:

User
 ├── Progress
 ├── Skills
 ├── Badges
 ├── Token Transactions
 └── Tutoring Sessions

---

Live Peer-to-Peer Tutoring

The platform supports real-time tutoring sessions between users.

A typical workflow is:

Learner
   ↓
Find Tutor
   ↓
Request Session
   ↓
Tutor Accepts
   ↓
Session Created
   ↓
WebRTC Connection
   ↓
Live Video Call
   ↓
Session Complete
   ↓
Token Settlement

---

WebRTC Video Calls

WebRTC was used for real-time peer-to-peer communication.

It enables the application to support:

• Video

• Audio

• Microphone controls

• Camera controls

• Real-time communication

The goal is to allow two users to communicate directly with low latency.

---

WebRTC Connection Architecture

A simplified flow is:

Learner App                     Tutor App
     │                              │
     │──── Session Request ────────►│
     │                              │
     │◄──── Signaling Server ──────►│
     │                              │
     └──────── WebRTC P2P ──────────┘
              Audio / Video

The backend handles signaling and session coordination while WebRTC handles the real-time media connection.

---

Signaling

WebRTC requires signaling to allow peers to exchange connection information.

The Phoenix backend can coordinate:

• Session creation

• Peer connection information

• Session status

• Connection events

After the peers establish a connection, the media stream can flow through WebRTC.

---

Tutor Profiles

Tutors can have profiles containing:

• Name

• Profile image

• Skills

• Experience

• Teaching categories

• Session cost

• Availability

• Rating or feedback where implemented

• Completed sessions

This helps learners select appropriate tutors.

---

Tutor Discovery

Learners can find tutors based on:

• Skill

• Category

• Experience

• Availability

• Rating

• Token cost

Example:

Python
──────────────
Tutor A
Beginner Python
20 Tokens

Tutor B
Python + APIs
30 Tokens

---

Tutoring Session Booking

A learner can request or schedule a tutoring session.

The workflow is:

Select Skill
    ↓
Select Tutor
    ↓
View Availability
    ↓
Select Session
    ↓
Token Validation
    ↓
Confirm
    ↓
Tutoring Session

---

Session Management

The system can track:

• Scheduled

• Waiting

• Active

• Completed

• Cancelled

• Expired

This allows the backend to maintain a reliable tutoring lifecycle.

---

Gamification System

Gamification was implemented to increase learner engagement.

The system can reward:

• Lesson completion

• Learning streaks

• Tutoring

• Skill milestones

• Challenge completion

• Community participation

The objective is to make progress visible and motivating.

---

Progress Badges

Users can unlock badges based on achievement conditions.

Examples:

First Lesson

Complete your first micro-lesson.

7-Day Learner

Maintain a seven-day learning streak.

Skill Explorer

Complete lessons across multiple categories.

Community Tutor

Complete your first tutoring session.

Knowledge Sharer

Teach multiple learners.

---

Badge Architecture

A badge can have:

Badge
├── Name
├── Description
├── Icon
├── Requirement
├── Category
└── Unlock Status

The backend evaluates achievement conditions and awards badges.

---

Learning Streaks

The application can track consecutive learning days.

Example:

Monday     ✓
Tuesday    ✓
Wednesday  ✓
Thursday   ✓
Friday     ✓

5-Day Streak

Streaks can encourage users to maintain consistent learning habits.

---

User Progress Dashboard

The learner dashboard can display:

• Completed lessons

• Current learning path

• Progress percentage

• Current streak

• Earned badges

• Tokens

• Tutoring sessions

• Skills learned

Example:

MY PROGRESS

Lessons Completed       28
Current Streak           7 Days
Badges                   6
Tokens                   145
Skills                   4

---

Android Application Navigation

The mobile application can use a navigation structure such as:

Home
Learn
Tutors
Exchange
Progress
Profile

The final navigation can be adapted based on product requirements.

---

Home Screen

The home screen serves as the personalized learning dashboard.

It can include:

Good Morning

Continue Learning
[5-Minute Lesson]

Recommended Skills
[Python] [Korean] [Design]

Your Progress
████████░░ 80%

Upcoming Tutoring
Tomorrow — 7:00 PM

Current Streak
7 Days

---

Learning Screen

The learning area allows users to browse and consume micro-lessons.

It can include:

• Categories

• Search

• Recommended lessons

• Learning paths

• Video lessons

• Progress indicators

---

Lesson Detail Screen

Before starting a lesson, the user can see:

• Lesson title

• Duration

• Skill category

• Learning objectives

• Difficulty

• Completion status

Then the user starts the video lesson.

---

Interactive Learning

Although the core learning format uses short videos, lessons can be extended with interactive components such as:

• Questions

• Knowledge checks

• Quick challenges

• Reflection prompts

• Completion actions

This creates a more active learning experience than passive video consumption.

---

Skill Exchange Screen

The skill exchange section connects learners and tutors.

It can display:

I Want to Learn
        ↓
Select Skill
        ↓
Find Tutors
        ↓
Compare
        ↓
Book Session

---

Token Wallet

Users can view their internal token balance.

Example:

SKILL TOKENS

Balance
245

Earned
+300

Spent
-55

[Transaction History]

This makes the skill economy understandable.

---

Token History

Users can inspect previous token activity.

Example:

+50  Teaching Session
-25  Python Tutoring
+30  Challenge Reward
-20  Design Session

This improves transparency.

---

Tutor Dashboard

Users who teach can have a tutor-oriented dashboard.

It can show:

• Upcoming sessions

• Completed sessions

• Skills offered

• Tokens earned

• Learner feedback

• Teaching statistics

This encourages users to contribute knowledge to the platform.

---

Dual User Model

The application does not require users to choose permanently between being a learner and a teacher.

A single account can support both roles.

                    USER
                     │
             ┌───────┴───────┐
             ▼               ▼
          LEARNER          TUTOR
             │               │
          Spend           Earn
          Tokens          Tokens
             │               │
             └───────┬───────┘
                     ▼
               Skill Exchange

This is one of the core differentiators of the platform.

---

Elixir/Phoenix Backend

The backend was developed using Elixir and Phoenix.

Phoenix is well suited to applications requiring:

• Real-time communication

• Concurrent connections

• WebSocket communication

• Event-driven systems

• Scalable backend services

These characteristics make it particularly appropriate for a platform combining live tutoring with a large number of connected users.

---

Phoenix Channels

Phoenix Channels can be used to manage real-time events between the Android application and backend.

Potential events include:

• Tutor availability

• Session invitations

• Session status

• Chat messages

• WebRTC signaling

• Notifications

A simplified architecture is:

Android
   ↓
Phoenix Channels
   ↓
Real-Time Events
   ↓
Tutor / Learner

---

Real-Time Session State

Redis can maintain short-lived session state such as:

• Tutor online status

• Active session

• Session locks

• Availability

• Connection state

This allows the system to quickly access frequently changing information.

---

PostgreSQL + Redis Architecture

The platform uses the two databases for different purposes.

                 BACKEND
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
     PostgreSQL             Redis
     Persistent             Fast State
        Data                 & Cache
          │                   │
          ├── Users           ├── Sessions
          ├── Lessons         ├── Presence
          ├── Progress        ├── Cache
          ├── Tokens          ├── Locks
          └── Badges          └── Counters

This separation provides a practical architecture for a real-time learning platform.

---

Token Transaction Integrity

Because tokens have economic value within the platform, token operations need to be controlled by the backend.

The client should never simply submit:

"Give me 500 tokens"

Instead:

User Action
    ↓
Backend Validation
    ↓
Check Eligibility
    ↓
Calculate Reward
    ↓
PostgreSQL Transaction
    ↓
Token Balance Updated

This prevents users from manipulating token balances through the Android client.

---

Database Transactions

PostgreSQL transactions can be used when token balances and transaction records must be updated together.

For example:

BEGIN
 ↓
Validate Balance
 ↓
Create Token Transaction
 ↓
Update Balance
 ↓
Create Session
 ↓
COMMIT

If a critical operation fails, the transaction can be rolled back.

---

Anti-Abuse Controls

A skill exchange platform needs protection against users attempting to exploit the reward system.

Potential controls include:

• Server-side token validation

• Rate limiting

• Session verification

• Duplicate transaction prevention

• Tutor session verification

• Abuse reporting

• Account restrictions

• Transaction logs

---

Video Streaming Performance

Short video lessons still require efficient delivery.

ExoPlayer handles playback while the video infrastructure can provide optimized streaming.

Important considerations include:

• Buffering

• Adaptive playback

• Network conditions

• Video resolution

• Startup latency

• Playback recovery

The objective is to allow users to start a lesson quickly even when network conditions vary.

---

Mobile Network Optimization

The application was designed for users who may switch between:

• Wi-Fi

• 4G

• 5G

• Variable mobile connections

Video quality and API usage should therefore be managed efficiently.

---

WebRTC Performance

Live tutoring requires low-latency communication.

The WebRTC implementation was designed around:

• Connection establishment

• Audio/video state

• Camera controls

• Microphone controls

• Session lifecycle

• Network changes

The application can also provide fallback states when a connection becomes unstable.

---

Camera & Microphone Permissions

Because live tutoring uses camera and microphone access, the application handles Android runtime permissions appropriately.

Users are informed about why the permissions are required before starting a live session.

---

Security

Security measures include:

• HTTPS

• Secure authentication

• Server-side authorization

• Protected API endpoints

• Token transaction validation

• PostgreSQL access controls

• Redis access restrictions

• WebRTC session authorization

• Input validation

• Rate limiting

The application does not trust the mobile client with sensitive business decisions.

---

Development Process

Phase 1 — Product & Learning Model Analysis

We defined:

• Micro-learning structure

• Skill categories

• Tutor model

• Token economy

• Gamification

• Learning progress

• Live tutoring workflows

---

Phase 2 — Mobile Application Architecture

The Android architecture was designed using Kotlin and Jetpack Compose.

Core areas were separated into:

• UI

• State

• Networking

• Learning

• User profiles

• Token management

• Tutoring

---

Phase 3 — Video Learning

ExoPlayer was integrated to support short-form lesson playback.

---

Phase 4 — Backend Development

Elixir/Phoenix services were developed for API and real-time application functionality.

---

Phase 5 — Database Architecture

PostgreSQL was designed for persistent application data while Redis was introduced for caching and fast-changing state.

---

Phase 6 — Skill Exchange

Tutor discovery, session requests, token requirements, and skill exchange workflows were implemented.

---

Phase 7 — WebRTC Integration

Real-time peer-to-peer video tutoring functionality was integrated.

---

Phase 8 — Gamification

Progress tracking, achievements, badges, and learning streaks were implemented.

---

Phase 9 — Token Economy

Token earning, spending, balances, and transaction history were developed with server-side validation.

---

Phase 10 — Performance Optimization

Video playback, API requests, real-time connections, database queries, and caching were optimized.

---

Phase 11 — Security & Reliability

Authentication, authorization, token integrity, session handling, and abuse controls were addressed.

---

Phase 12 — Testing

The platform was tested across:

• Lesson playback

• Progress tracking

• Tutor discovery

• Session booking

• WebRTC calls

• Token transactions

• Badges

• Learning streaks

• Real-time events

• Database operations

• Network failures

• Authentication

• Mobile UI

---

Key Technical Challenges

Challenge 1 — Combining Micro-Learning With Live Tutoring

Video lessons and live tutoring have different technical requirements.

Recorded lessons prioritize efficient streaming, while tutoring requires real-time low-latency communication.

The architecture therefore used:

ExoPlayer for lessons + WebRTC for live sessions.

---

Challenge 2 — Real-Time Communication

Live tutoring requires reliable communication between users.

Phoenix real-time infrastructure and WebRTC were used together to coordinate sessions and establish peer-to-peer media communication.

---

Challenge 3 — Token Integrity

Because tokens determine access to tutoring sessions, the token economy could not rely on client-side logic.

Token transactions were controlled by the backend and persisted through PostgreSQL.

---

Challenge 4 — High-Frequency State

Tutor availability, active sessions, and connection-related state can change rapidly.

Redis was used for fast-access state and caching where appropriate.

---

Challenge 5 — Gamification Without Overcomplication

Gamification had to encourage learning rather than distract from it.

Badges, progress, streaks, and tokens were therefore connected directly to meaningful learning activities.

---

Business Impact

The platform gives the South Korean EdTech business a differentiated learning model built around knowledge exchange rather than traditional course purchasing.

The application can help users:

• Learn in short sessions

• Build consistent learning habits

• Discover new skills

• Find peer tutors

• Teach their own skills

• Earn internal tokens

• Spend tokens on tutoring

• Track progress

• Unlock achievements

• Build a learning community

The core transformation was:

Traditional online learning → micro-learning + peer tutoring + gamified skill exchange.

---

Why Kotlin & Jetpack Compose Were Used

Kotlin provides a modern foundation for native Android development, while Jetpack Compose enables declarative and reusable UI development.

Together they support an application with highly dynamic screens such as:

• Lesson feeds

• Video players

• Progress dashboards

• Tutor profiles

• Token wallets

• Live tutoring screens

• Badges

• Learning paths

---

Why ExoPlayer Was Used

ExoPlayer was selected for the recorded lesson experience because the application depends heavily on short-form video learning.

It provides control over:

• Streaming

• Playback

• Buffering

• Seeking

• Playback state

• Video presentation

This makes it appropriate for a micro-learning platform where video is a primary learning format.

---

Why WebRTC Was Used

WebRTC was used for peer-to-peer live tutoring because it provides real-time audio and video communication.

Unlike recorded lessons, tutoring requires two-way communication between participants.

Therefore:

ExoPlayer = recorded learning

WebRTC = live learning

---

Why Elixir/Phoenix Was Used

Elixir and Phoenix provide a strong foundation for applications requiring concurrent connections and real-time communication.

For this platform, Phoenix can manage:

• APIs

• Real-time events

• WebSocket communication

• Session coordination

• WebRTC signaling

• User presence

This makes it suitable for a platform with potentially many simultaneous tutoring sessions.

---

Why PostgreSQL Was Used

PostgreSQL provides reliable persistent storage for important application data.

It is appropriate for:

• User accounts

• Learning progress

• Courses

• Lessons

• Tutoring sessions

• Token transactions

• Badges

• Skill information

---

Why Redis Was Used

Redis was used where very fast access to temporary or frequently changing information was beneficial.

Examples include:

• Caching

• User presence

• Tutor availability

• Session state

• Rate limiting

• Token-related temporary state

Persistent token records remain in PostgreSQL.

---

Future Expansion

The platform can be expanded with:

• AI personal learning assistant

• AI tutor matching

• AI lesson generation

• AI skill assessment

• AI pronunciation coaching

• AI code tutoring

• Automated lesson recommendations

• Personalized learning paths

• Voice-based tutoring

• Group video classrooms

• Screen sharing

• Collaborative whiteboards

• Skill certifications

• Tutor reputation scores

• Advanced token marketplace

• Corporate learning programs

• Multi-language support

• iOS application

• Web application

A future AI tutor-matching system could work like:

Learner
   ↓
"I want to learn Python"
   ↓
AI Matching Engine
   ↓
Analyze:
Skill
Level
Availability
Learning Goals
Tutor Reputation
   ↓
Recommended Tutors
   ↓
Book Session

---

Technology Stack

Mobile Application

• Kotlin

• Jetpack Compose

• Android SDK

Video Learning

• ExoPlayer

• Video Streaming

• Playback Management

Real-Time Communication

• WebRTC

• Phoenix Channels

• Real-Time Session Signaling

Backend

• Elixir

• Phoenix

• REST APIs

• WebSockets

Database

• PostgreSQL

• Redis

Core Platform Features

• 5-Minute Micro-Lessons

• Video Learning

• Peer-to-Peer Tutoring

• Live Video Calls

• Skill Exchange

• Token Economy

• Progress Tracking

• Learning Streaks

• Achievement Badges

• Tutor Profiles

• Learning Paths

• User Dashboard

---