NihonGo! is a full-stack Japanese learning platform for English speakers. It helps learners study hiragana, katakana, kanji, vocabulary, and grammar through structured lessons, interactive exercises, progress tracking, and custom flashcard decks.
After submitting NihonGo!, I found out that Render was not an accepted deployment option for this project. I also realized that Render’s free tier can put services to sleep after periods of inactivity, which is not ideal for a project that reviewers and users need to test reliably.
To fix this, I migrated the deployment away from Render:
The main reason for this change was reliability. Since Render can make free services inactive when there is no traffic for a while, the app could appear broken or slow when someone tries to test it later. Moving the app to Vercel and Neon makes the project easier to access, test, and review.
The new deployment is now working correctly, with the frontend, backend, database, authentication, and CORS all connected again.
Since the last devlog, I focused on preparing NihonGo! for a more complete public release. I expanded the learning content with new seeders for more hiragana, katakana, N5 kanji, and beginner lessons covering particles like を, に, の, questions with か, and polite ます verbs. I also added backend tests with Jest and Supertest to validate the API health check, protected dashboard routes, and unknown route handling.
On the frontend, I repolished the landing page to better present the app as a full Japanese learning platform, with clearer calls to action, feature highlights, preview stats, and a stronger visual identity. I also added a custom favicon and included a preview GIF so the project feels more complete and presentable from the first visit.
Finally, I prepared the project for deployment: I configured the backend for production PostgreSQL over SSL, added the proper start/test scripts and dependencies, consolidated the documentation into a full project README, and published the live demo on Render at nihongo-udug.onrender.com. With this, NihonGo! now has content, documentation, tests, production configuration, and a working public deployment.
Since the last devlog, I focused on making the dashboard more complete and data-driven. On the backend, I refactored the dashboard service and presenter, expanded the statistics service to return quick stats, daily goal progress, and recent activity, adjusted progress handling, added a migration for renamed character progress columns, cleaned up unused code, and updated the API docs.
On the frontend, I connected the new dashboard data to polished cards for Daily Goal, Recent Activity, Recommended Lessons, and Quick Stats. I also improved module/exercise UI details, cleaned up duplicated or unused components, fixed naming and lint issues, and made small page-level adjustments across the app.
I also expanded the Flashcards feature into a fuller management flow: fetching deck details, editing and deleting decks, editing and deleting cards, refreshing due cards and progress after actions, and resolving warnings around the page state. This makes flashcards feel much closer to a complete study tool rather than just a basic review screen.
Today I expanded NihonGo with new learning flows for practice and review. On the backend, I added the dashboard recommendation feature, connecting lesson progress, quick stats, and recommendations so users can continue unfinished lessons or start the next suggested lesson.
On the frontend, I improved the Dashboard with modular cards for continuing learning, daily goals, recent activity, recommendations, and quick stats. I also built the Kana/Kanji Trainer page with filters, progress tracking, random practice, answer submission, and instant feedback.
I also implemented the Flashcards experience, including deck creation, card creation, due-card review, answer reveal, and progress tracking. Finally, I cleaned up page exports/routes and fixed integration bugs across auth, exercises, module details, and flashcard behavior.
Since the last update, I shifted the backend toward a clearer screen-driven architecture by introducing dedicated screen services and presenters. This included the first lesson screen flow, with a new lesson endpoint and controller designed to return lesson content in a frontend-friendly shape. I also prepared the presentation layer to merge lesson data with user progress details, setting up cleaner contracts between API and UI.
I then expanded the dashboard API with a v2 response format focused on frontend consumption. The dashboard service now aggregates the user’s latest studied lesson plus quick stats in one place, and maps them into a structured payload for cards like Continue Learning, Lessons Completed, Exercise Accuracy, Characters Mastered, and Flashcards Reviewed. This makes the home experience more actionable and reduces data assembly work on the client side.
To support this, I improved backend organization by separating domain services from screen services and updating controllers to use the new structure. I also added supporting progress/statistics functions to centralize calculations and keep business logic out of route handlers. Overall, this sprint was about making the backend more scalable, consistent, and aligned with the next frontend iterations.
Since the last update, I pushed NihonGo! into the actual learning flow instead of just the dashboard. The modules page now pulls real progress data from the backend and presents each JLPT module as a clickable card, with loading, error, and empty states to make the experience feel complete and stable.
I also added dedicated module and lesson detail pages. Module pages now show overall completion and the full list of lessons, while lesson pages display the explanation content together with exercise previews, making the study journey feel much more structured. To keep everything consistent, I introduced reusable UI pieces like page headers, badges, empty states, and lesson/exercise cards.
I moved the front-end from setup mode into a real product experience by building the first complete dashboard screen for NihonGo!. The dashboard now loads live summary data from the API, greets the user, shows their current study progress, and highlights what they should continue next. I also added proper loading and error states so the page feels stable instead of empty.
To support that, I created a small set of reusable UI pieces like cards, stat blocks, and a progress bar, which made the interface much easier to structure and keep consistent. With that in place, the front-end now feels like the beginning of a full learning platform instead of just a shell around the authentication flow.
I started turning NihonGo! into a real frontend app by setting up the main routing structure and global providers for authentication and theme control. That gave the project a proper foundation, with protected routes for the learning area and a shared app layout that keeps navigation consistent across the site.
From there, I built the first visible pieces of the interface: a landing page, a styled auth layout, and a functional login screen. I also added reusable form components, API error handling, and session logic so the frontend can talk to the backend, keep users logged in, and send them to the dashboard when authentication succeeds.
Since the last update, I worked on the backend’s security and request-handling layer. I added validation schemas with Zod across the main routes, including auth, progress, trainer, and flashcards, so the API now validates params, query strings, and request bodies more consistently.
I also improved the app structure with a rate limiter, a not-found middleware, and stronger error handling for validation and database issues. On top of that, I added CORS configuration and request logging with Morgan in development.
This was also my first time using both Zod and Morgan, so this update was useful for learning how to structure validation and logging in a more organized way.
Since the last update, I added a dashboard layer that brings together the main learning data in one place. The backend now exposes a dashboard summary route that aggregates progress across lessons, exercises, trainer characters, and flashcards, along with recent activity for each area.
I also kept improving the flashcards flow by fixing the due-cards logic and adding example flashcard seed data. The app now includes the new dashboard routes, so the API is starting to feel more complete and connected across all study features.
Since the last update, I implemented a complete Flashcards module end-to-end. This included new database migrations and models for decks, cards, and card reviews, plus the associations needed to connect users, decks, and review history.
I also finished the full MVC flow for flashcards:
create, list, view, update, delete).create, update, delete).On the logic side, I added mastery score calculation and a spaced-review style due-date strategy based on correct and wrong attempts. I also fixed integration issues from this cycle, including model naming, async promise handling, and boolean behavior in requests.
Since the last devlog, I added the trainer system for study characters. The backend now supports listing characters, fetching random practice sets, submitting character answers, and tracking each user’s trainer progress.
I also seeded the first batch of hiragana, katakana, and a few kanji so the trainer has real content to work with. On top of that, I wired the new trainer and progress routes into the app and fixed a few implementation issues around model names, async handling, and boolean values.
Since the last devlog, I added the first version of the progress layer for users. The new service now tracks exercise submissions, lesson progress, and module progress, so the backend can calculate completion and score instead of only serving content.
I also adjusted the models and associations to support that progress data, and fixed some import/export and naming issues along the way. The app is moving from content delivery to actual study tracking, which is the main step forward in this update.
Since the last update, I finished the first full content layer of the backend. I added a content service that can fetch modules, individual modules with their lessons, lessons with their parent module, and lesson exercises with answer options. This turned the database schema into something the API can actually serve.
I also created the content controller and routes, then mounted them in the main app under /api/content. At the same time, I added an initial content seeder to populate the database with JLPT module data, lessons, exercises, and multiple-choice options so the API has real content to work with right away.
After that, I fixed a few integration issues, including import/export problems and some attribute name typos, so the content queries and models line up correctly. The backend is now in a much better state: authentication is in place, content endpoints are wired, and the database can be seeded with starter learning material.
Since the last update, I expanded the backend schema beyond authentication and started modeling the learning content structure of NihonGo. I added the core Sequelize models for course modules, lessons, exercises, and exercise options, along with the relationships between them so the content can be loaded in a structured way.
The project now supports a full content hierarchy: modules contain lessons, lessons contain exercises, and exercises can contain multiple answer options. I also kept the user model in place for authentication, with roles already prepared for future access control.
On the database side, I created and ran the migrations needed to make these tables available in PostgreSQL. The schema is now in a usable state for starting content seeding and API endpoints for lessons and exercises.
Since the last update, I focused on turning the backend into a real authentication API. I created the User model and its migration, then added the auth service layer to handle registration and login logic. I also built a token utility with JWT so authenticated users can receive access tokens after signing in.
On top of that, I added an auth controller, auth routes, and a global error middleware to keep the API responses consistent. The main app was updated to use the new auth routes and the error handler, and the Sequelize setup was adjusted to load the shared config correctly.
cors, helmet, and JSON parsing enabled.