Gio – Intelligent ENEM Study Scheduler

Gio is an AI-powered study scheduler built for a real student preparing for the ENEM (Brazil's national college entrance exam). Rather than a linear checklist, it uses a multi-factor priority algorithm to decide what to study each day across 45+ topics, automatically reorganizes the schedule every night using GPT-4o-mini, and enforces spaced repetition based on self-reported confidence. The student sets a target exam date and available study hours; Gio distributes all topics to the deadline and adapts daily.

ENEM preparation spans months and dozens of subjects with wildly different difficulty levels and historical exam frequencies. Most students either follow a rigid linear plan (which ignores what they've already mastered) or study reactively (whatever feels hardest today). Neither approach optimizes the time-to-score ratio. A custom solution was needed that could reason about difficulty, frequency, confidence, and recency simultaneously — and recover gracefully when the student skips a day.

Build a two-service application (Next.js frontend + Express backend) that: (1) computes a daily priority-ranked study list; (2) surfaces a single 'Focus of the Day' topic; (3) tracks confidence per topic after each session; (4) rebuilds the upcoming week's schedule automatically every night with GPT-4o-mini; (5) visualizes progress via weekly planner and calendar heatmap.

• ◈Solo developer — architecture, frontend, backend, database, AI integration

1. 01Multi-factor priority score — score = difficulty_weight + enem_frequency_weight + (5 − avg_confidence) × 0.6 + days_since_studied × 0.1. Four independent signals blended into one number: prevents starvation of medium-difficulty but high-frequency topics that a pure difficulty ranking would deprioritize.
2. 02GPT-4o-mini for nightly reorganization — implementing a custom constraint-satisfaction algorithm (3 tasks/day, ≤195 min total, balanced disciplines) is hard to maintain. GPT-4o-mini reasons about all constraints in natural language, outputs a structured JSON schedule, and explains its reasoning. Temperature 0.2 keeps output consistent; JSON-mode forces parseable responses.
3. 03node-cron at 23:30 for automatic reorganization — students don't check the app at end of day. A server-side cron rebuilds the next 7 days each night so the student wakes up to a realistic schedule that already accounts for what was and wasn't completed.
4. 04Supabase (São Paulo region) as the database — no DevOps required, RLS available, real-time subscriptions ready for future features. Regional choice minimizes latency for Brazilian users.
5. 05Separate frontend/backend repos — Next.js App Router on Vercel, Express on a separate host. Enables independent scaling and avoids cold-start latency on the Node backend from serverless constraints.
6. 06Confidence (0–5) as the central state metric — most study apps track completion (binary). Confidence captures nuance: a student can 'complete' a session but feel 2/5 confident. Spaced repetition intervals shorten when confidence is low, ensuring weak topics revisited more aggressively.
7. 07Focus of the Day as a decision-relief feature — when overwhelmed, students need one clear answer. The API calculates the single highest-priority topic and surfaces it prominently, reducing decision paralysis and increasing adherence.

• →AI reorganization must be designed for failure modes: GPT-4o-mini occasionally omits topics or produces malformed JSON. A local fallback algorithm (pure priority score, no AI) runs when the API fails or returns invalid output — the student always gets a schedule.
• →Confidence as state is more honest than completion: the two-week beta showed students marking tasks complete at confidence 2/5 frequently. Adding a mandatory confidence rating after each session changed behavior — students started revisiting topics they thought they'd 'finished'.
• →node-cron in a long-running Express process is simpler than serverless scheduled functions for this use case: one less deployment target, no cold-start delay on the nightly job, and the reorganization context (previous days' tasks) is already in memory.
• →Supabase RLS should be designed upfront: disabling it for development and retrofitting it later caused a schema refactor. The lesson is to model row-level access alongside the data model, not after it.

Functional — used by a real student for active ENEM preparation