Daily Native English
A full-stack Next.js English-learning app for Chinese-speaking learners who want daily, practical lessons in natural everyday expression.
Problem
Many Chinese-speaking learners can understand English but still sound stiff, formal, or translated when they need casual workplace and everyday phrasing.
What I did
Longsheng designed and implemented the product flow, AI lesson generation, database model, route handlers, local learning state, and mobile-first UI.
Stack
Challenges
- Keeping the homepage useful even when the daily OpenAI generation job has not finished or has failed.
- Designing lesson content around naturalness, tone, learner mistakes, and Chinese cultural notes instead of generic vocabulary drills.
- Supporting practice, notes, streaks, flashcards, and expression difficulty without requiring user accounts in the MVP.
- Protecting cost-bearing AI routes while keeping public lesson browsing simple and low-friction.
Tradeoffs
- Demand-driven generation avoids cron infrastructure, but the first visitor of the day may see yesterday's lesson while generation runs in the background.
- localStorage keeps the MVP account-free, but notes, practice results, and progress do not sync across devices yet.
- Route Handlers keep server boundaries explicit, but every mutation needs a small API surface instead of relying on Server Actions.
Chinese-speaking English learners often know the grammar, but not the phrasing that makes a sentence sound like something a real person would say.
Daily Native English is my focused attempt to turn that gap into a daily practice product: one short lesson, one real situation, and a set of natural phrases that learners can use immediately.
What it is
Daily Native English is a full-stack web app for short daily English lessons. Each lesson is built around a specific everyday scenario and includes:
- A conversational article written for a 5-10 minute learning session
- Expressions with meaning, tone, usage notes, examples, awkward versions, and Simplified Chinese cultural notes
- Rewrite comparisons that show stiff English next to a more natural version
- Practice items, flashcards, TTS playback, notes, progress, and streak tracking
The product is intentionally mobile-first because the core habit is short, frequent practice rather than long study sessions.
Product shape
Daily lesson flow. The homepage loads today's lesson when it exists. If the lesson has not been generated yet, the app still shows the latest previous lesson and displays a fallback banner while the generation job runs after the response.
Learning surfaces. The app includes a lesson detail page, archive, phrase browser, flashcard mode, notes page, and progress card. Learners can browse by lesson, review expressions across lessons, mark expressions as new, and retry practice items they missed.
No-account persistence. Notes, practice results, streaks, font-size preference, and expression difficulty are stored locally. That keeps the MVP friction low while preserving storage interfaces that can be swapped for a database-backed user system later.
Technical architecture
The app uses Next.js App Router with Route Handlers for all API behavior. Public
routes provide today's lesson, paginated lesson lists, individual lessons,
expressions, TTS, transcription, feedback, category preference, and random
lessons. Internal routes are protected by an x-internal-secret header for
manual generation and seed operations.
The data layer is Neon PostgreSQL with Drizzle ORM. The core schema includes
lessons, expressions, rewritePairs, practiceItems, and generationJobs.
Generation jobs track status, attempts, timestamps, errors, model, prompt
version, and raw response so failures can be debugged after the user-facing page
has already returned useful content.
OpenAI is used server-side only. Lesson generation currently uses a prompt
versioned as v4, with recent lesson context and scenario rotation to reduce
topic repetition. TTS and transcription routes are protected by origin checks
through middleware because those endpoints carry direct API cost.
Security and data boundaries
The project deliberately avoids authentication in the current scope. That keeps the product easy to try, but it also means all learner-specific state is device-local until the planned anonymous identity phase.
Server-only boundaries are explicit: the OpenAI client is created in a shared
server utility, API keys are read from environment variables, and client
components call Route Handlers instead of importing AI or database code.
Cost-bearing routes such as /api/tts and /api/transcribe require an allowed
origin configured by environment variable.
Current status
Active development. The MVP product surface is in place, and the project plan shows Phase 0 and Phase 2 as complete, Phase 1 mostly complete, and Phase 3 focused on remaining technical polish.
Implemented areas include daily lesson loading, lazy lesson generation, archive/search, expressions browsing, flashcards, shadow practice on desktop, TTS, local notes, practice persistence, streaks, feedback, category preference, and a mobile/desktop navigation layout.
What's next
- Add the remaining technical quality work from Phase 3, including internal health status, stuck-job healing, infinite-scroll debounce, and exact tone filtering
- Finish the PWA manifest and install path
- Use lesson feedback and category distribution to improve future generation
- Add anonymous identity so notes, practice, and progress can sync across devices without introducing full login friction
- Explore AI conversation practice once identity and rate limiting are in place