For our course project, my teammate and I were asked to build something with the help of Replit. We wanted a useful application, not just a page that looked good in a screenshot.
We chose to build an Arabic student project management platform: a place where an instructor can publish assignments, students can organize their teams and work, and project submissions can receive structured feedback.
The application focuses on a single course and follows the project from assignment creation to published evaluation.
This article explains what we built, the technologies behind it, and what we learned while working with an AI coding agent.
The Problem We Wanted to Solve
A student project involves more than submitting a final link.
Students need to understand the requirements, form a team, divide responsibilities, track progress, and know which version they submitted. Instructors need to manage deadlines, define grading criteria, review submissions, and communicate results.
When these steps are spread across messages and unrelated tools, it becomes harder to keep track of what happened.
Our goal was to bring that workflow into one application, with separate experiences for instructors and students.
What the Platform Does
The Instructor Workflow
An instructor can create an assignment and define:
The project requirements.
The submission deadline.
Team-size limits.
The late-submission policy.
The grading rubric.
Assignments have draft, published, and closed states. This separates preparation from the point when an assignment becomes available to students.
After students submit their work, the instructor can evaluate it against the rubric. Evaluations can remain drafts until the instructor publishes the results.
That distinction matters: saving feedback should not automatically make unfinished grading visible to students.
The Student Workflow
Students can view published assignments, create or join a team using an invitation code, and organize their work.
Within a team, they can create tasks, assign responsibilities, and update task status. This makes the team's progress easier to follow than relying only on informal messages.
Students submit their project through an HTTPS link. The platform keeps submission versions so that a later update does not simply erase the earlier submission record.
Once an evaluation is published, students can view the results and feedback.
The main workflow is:
Published assignment
↓
Team formation
↓
Tasks and responsibilities
↓
Versioned project submissions
↓
Instructor evaluation
↓
Published results
Why We Built an Arabic Interface
We wanted the interface to fit the people using it.
The application uses Arabic text and a right-to-left layout. This affects more than translation: navigation, alignment, forms, and the order of visual elements all need to feel natural.
We used the Cairo font and kept the interface focused on the course workflow.
The current application is Arabic-first. A language switcher is not part of the current scope.
The Technology Stack
We used TypeScript across the frontend and backend.
Area Technologies
Frontend React 19, Vite, TypeScript
Routing React Router 7
Styling Tailwind CSS 4 and the Cairo font
Server data TanStack Query 5
Forms and validation React Hook Form and Zod
Backend Node.js 22 and Express 5
Database PostgreSQL
Database access Drizzle ORM
Authentication Replit Auth
Automated testing Vitest and Supertest
Code quality ESLint and Prettier
Workspace tooling pnpm
The frontend communicates with an Express API, which applies business rules and reads or writes data in PostgreSQL.
React frontend
│
│ HTTP requests
▼
Express API
│
│ Validation and authorization
▼
PostgreSQL database
Shared validation schemas help keep the frontend and backend consistent about the shape of application data.
Authentication: From a Temporary Demo to Real Accounts
Authentication was one of the decisions we revisited during development.
Our original plan included Clerk. We initially used a development-only demo mode to explore the application before completing real authentication.
We then chose Replit Auth, allowing users to sign in with their Replit accounts.
The temporary demo mode is disabled in the current configuration. It was a development aid, not a substitute for authentication with real users.
For new users, the application creates a student account by default unless their verified email is configured for instructor access. This prevents a new user from choosing an instructor role through the interface.
We also manually checked login and logout as part of reviewing the application.
Permissions Must Exist on the Server
One important lesson was that hiding a button is not enough.
A student should not be able to publish an assignment just because they know an API endpoint. A user should not be able to change another team's work by sending a different identifier.
The backend checks the authenticated user, their role, and their relationship to the requested data before allowing protected actions.
These checks cover distinctions such as:
Instructor actions versus student actions.
Team members versus users outside the team.
Team-leader actions versus other team-member actions.
Draft evaluations versus published results.
The interface helps users understand what they can do, but the server enforces those rules.
Business Rules Matter as Much as Screens
A form can look complete while still allowing an invalid action.
For this project, the application also needs to consider assignment state, team-size limits, submission deadlines, and the late-submission policy.
Those rules connect different parts of the application. For example, submitting a project is not just saving a URL: the server must also check who is submitting it, which team it belongs to, and whether the assignment permits the submission.
Thinking through those connections helped us move beyond treating the application as a collection of separate pages.
How We Worked with Replit Agent
We want to be clear about the role of AI in this project.
Replit Agent wrote the application code. My teammate and I worked on choosing the problem, defining requirements, discussing alternatives, reviewing the results, and trying the application.
We did not manually write every component or backend route, and we do not want to present the project as if we did.
Our responsibility was to make decisions and understand the system we were asking the agent to build.
That included questions such as:
What belongs in the first version?
Which actions should each role be allowed to perform?
When should a student see an evaluation?
How should submission updates be recorded?
Which authentication approach fits our project?
Working with an AI agent did not remove the need for those decisions. It made clear requirements and careful review more important.
Testing and Reviewing the Application
We used automated checks and manual review.
The project includes automated tests for backend behavior, authentication, and authorization scenarios. TypeScript checks, linting, and production builds provide additional checks for implementation problems.
We also manually tried login and logout.
These checks serve different purposes. Automated tests can verify repeatable conditions, while manual review helps us notice whether the experience makes sense to a user.
Passing tests does not prove that an application is free of bugs or that every security risk has been eliminated. It gives us evidence about the specific behavior that was checked.
Keeping the First Version Focused
We deliberately kept the application focused on one course.
The current version does not include:
Multi-course administration.
Built-in chat.
Direct file uploads.
AI features inside the student platform.
Students submit project links rather than uploading files.
Using AI to help build the application is different from adding AI features to the application itself.
Keeping those boundaries made it easier to concentrate on a connected workflow: assignments, teams, tasks, submissions, and evaluations.
What We Learned
- A Clear Workflow Is More Useful Than a Long Feature List The value of the platform comes from the connection between its features.
Publishing an assignment leads to team work, which leads to submissions, which leads to evaluation. That sequence gives each screen a purpose.
- Authentication and Authorization Are Different Authentication answers who the user is.
Authorization answers what that user is allowed to do.
Both are necessary, especially in an application with instructor and student roles.
- Requirements Need Specific Rules “Students can submit projects” is only a starting point.
We also need to define which students, for which team, under which assignment state, and according to which deadline policy.
- AI-Generated Code Still Needs Human Review An AI agent can produce code, but we still need to evaluate whether the result matches the intended behavior.
That means checking the application, asking questions, understanding important decisions, and being honest about what has and has not been verified.
Possible Next Steps
Future improvements could include:
Support for multiple courses.
Notifications for deadlines and published evaluations.
More detailed progress reports.
An option to sign out of all devices.
These are possible extensions, not features included in the current version.
Final Thoughts
This project gave us a practical way to explore full-stack application development with the help of Replit Agent.
We built an Arabic platform that connects the main stages of a student project, from the instructor's assignment to the student's published evaluation.
The most useful part of the experience was not simply generating code. It was learning to define a useful problem, make concrete product decisions, review permissions, and connect individual features into a workflow.
For us, that made the project more meaningful than a collection of pages: it became a tool designed around how students and instructors actually work.
Top comments (0)