MERN School Management System: three branches and one rebuild in progress

The feature set is a school admin's day, written out as roles

The School Management System is a web-based application on the MERN stack, made up of MongoDB, Express.js, React.js and Node.js. Its stated aim is to simplify school management and class organization and to facilitate communication between students, teachers and administrators. The features are grouped by role, and there are three: Admin, Teacher and Student, each with specific functionalities and access levels. The admin dashboard is where the structure of the whole thing gets created, since administrators add new students and teachers, create classes and subjects, manage user accounts and oversee system settings. Teachers handle the per-class work: taking attendance, marking students present or absent, and generating attendance reports, and separately assessing performance by providing marks and feedback. Students see the results of that work, viewing their marks, tracking progress over time, and visualising performance data through interactive charts and tables. Messaging runs both ways between teachers and students. The technology list is short and specific, with React.js, MUI and Redux on the frontend, Node.js and Express.js on the backend, and MongoDB as the database.

The branch structure is the project's main design decision

The repository holds three branches and the README explains each one carefully, because the choice changes what you get. The main branch contains work reflecting the author's current standards, and the author is rebuilding the project architecture there with updated patterns, a cleaner structure and better practices than the original version. The community-version branch collects community contributions and external pull requests, and it stays separate from main while the core is rebuilt. The legacy-version branch contains the same code shown in the YouTube tutorial, so if you came from the video and want the exact version demonstrated there, you switch to it after cloning. The branch selection section spells out the decision rule. Learning from the video and wanting the same project means legacy-version. Wanting the original project but applying changes yourself also means legacy-version, modified as needed. Wanting the updated architecture means main, which the README says is under active development and contains major improvements. Wanting to contribute means community-version, since all external pull requests land there. The last push to the repository was on 2026-06-07 and there are no GitHub releases, so there is no tagged version to install.

Two terminals, two .env files, and a MongoDB URL you have to supply

The setup is a two-terminal workflow, one for the backend and one for the frontend. You clone the project first:

git clone https://github.com/Yogndrr/MERN-School-Management-System.git

If you want the tutorial version, switch branches before anything else:

git checkout legacy-version

Then in the backend terminal you install dependencies from the backend directory:

cd backend
npm install

The backend needs a .env file in the backend folder containing the database URL and a secret:

MONGO_URL = mongodb://127.0.0.1/smsproject

SECRET_KEY = 'secret123key'

The README says to fill MONGO_URL using the instructions further down and that SECRET_KEY is any random string. Starting the backend is npm start, and the frontend gets the same treatment in its own terminal with cd frontend, npm install, and a frontend .env file holding the API base URL:

cd frontend
npm install

REACT_APP_BASE_URL=http://localhost:5000

If a .env file already exists and the line is commented out, the comment has to be removed. The frontend is then started with npm start, the frontend runs at localhost:3000 and the backend at localhost:5000, and the REACT_APP_BASE_URL value is the only thing tying the two together.

MongoDB locally or on Atlas, and the difference matters for deployment

The database connection is a real decision rather than a formality, and the README splits it into two options depending on where you intend to run the app. For local development you need two components, the MongoDB server and Compass, the graphical client. You install MongoDB Community Server, which includes the mongod server, and Compass separately. On Windows and macOS the installer usually sets the service to run automatically, and if it is not running you start it manually with the mongod command. Compass then connects to a local instance using a connection string whose database name you choose, and you use that full string as your MONGO_URL. For a cloud database you create an Atlas account and a free cluster, then in the cluster page you choose Database, then Connect, then Connect your application. Atlas shows a connection string in the srv form, and you replace the placeholders and use the full string as your MONGO_URL. The README's guidance is blunt about the split: use Atlas if you plan to deploy the project. The local option with mongod running on your own machine has no place in a hosted deployment, so the choice made during setup determines what you have to change later.

Deployment splits the two halves across Render and a static host

The README is explicit that there are multiple ways to deploy the project and that you can use any combination depending on how you prefer to manage client and server. The backend goes to Render, which the README says works well for Express-based APIs and requires almost no infrastructure setup. You push your code to GitHub, create a new Web Service, select your backend folder as the root, set the build command to npm install and the start command to npm start, and add the required environment variables, MONGO_URL and SECRET_KEY. Render redeploys automatically on every push. The frontend goes to Netlify or Vercel, both of which build and serve the React application. On Netlify you create a project, set the build command to npm run build and the publish directory to build, then add an environment variable for the API endpoint if you need one. Netlify auto-builds on every push, and the README notes Vercel deploys React frontends with the same build command and the same publish directory. After both sides are up, you set the frontend environment variable to point at your backend URL, for example a Render URL, and rebuild the frontend, because the value is baked in at build time rather than read at runtime.

The README does not document the environment variable surface

There are gaps in the documentation that an adopter will hit, and it is worth naming them rather than guessing. The .env files are given as two keys for the backend and one for the frontend, and the README does not describe what else the application reads, so a deployment that needs more configuration will have to read the backend source to find it. The frontend variable is the one that matters most, and its name follows the Create React App convention of a REACT_APP_ prefix, which also means the value is embedded in the built bundle at build time. That is why the deployment section insists on rebuilding the frontend when the backend URL changes. The same reasoning applies to the Netlify and Vercel publish directory, which is build rather than dist, a detail that will confuse anyone arriving from a Vite project. There is no database seeding step described, no mention of a migration path for the data model, and no documented way to reset a database. For a demo project that is acceptable. For a system that will hold real student records, the absence of a documented seed, migration and backup procedure is the gap to close before you go further, and the repository has no releases, no issue-driven roadmap and an unclassified licence, so none of that documentation is coming from the upstream project.

Three roles with three different views of the same data

Looking at the feature list as a data model rather than a feature list explains why the code is organised the way it is. There are three core entities in any version of this problem: people who are taught, people who teach, and the classes and subjects that bind them. The admin creates the students and the teachers, creates the classes and subjects, and manages the user accounts, which means the class and subject records are the spine and everything else hangs off them. The teacher then operates within a class: attendance is per class per session with a present or absent mark, and marks plus feedback are per student within that class. The student sees the read-only side of exactly the same records, their own attendance, their own marks, and a chart view of progress over time. The Redux store on the frontend and the MongoDB collections behind the Express routes exist to serve those three views. The messaging feature is the one that cuts across the roles, since it is bidirectional between teachers and students, and it is the part of a school system where the data model gets interesting, because a message is addressed to a person rather than attached to a class. The description also credits another contributor for the original project, which is worth knowing if you go looking for the upstream version this was based on.

Editorial conclusion

The MERN School Management System suits a student or instructor who wants a complete, readable MERN example with roles, attendance, marks and charts, and it suits someone who wants a starting point for a school or campus tool they intend to reshape themselves. It is the wrong choice if you need a maintained product with a support commitment, since the repository publishes no releases, carries an unclassified licence and says outright that main is under active development during a rebuild. Verify first which branch you actually want, since the code differs substantially between them, that your MongoDB instance is reachable from the backend, and that the role and authentication model in the code matches what your institution needs before you build on it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Yogndrr/MERN-School-Management-System on GitHub