Building an Arabic Student Project Platform with Replit Agent

Eng-younesAsaad — Thu, 22 Oct 2026 18:12:44 +0000

For a course assignment, we were asked to build a software project with the help of Replit. As a team of two, we wanted to create something useful—not just a collection of pages, but an application with connected workflows, persistent data, and clear responsibilities.

We chose to build an Arabic platform for managing student projects.

The idea was to bring the project lifecycle into one place: publishing assignments, forming teams, organizing tasks, submitting work, and releasing evaluations.

This article explains what we built, the technologies we used, and how we worked with Replit Agent throughout the process.

The Problem We Wanted to Solve
A group project involves more than writing code.

An instructor needs to communicate requirements, set deadlines, follow team progress, review submissions, and publish grades. Students need to understand the assignment, organize their teams, divide responsibilities, and keep track of their work.

When these details are scattered across messages, documents, and shared links, important information can become difficult to find.

Our platform organizes these activities around a single course, with two main roles: instructor and student.

What the Platform Does
The Instructor Workflow
An instructor can create an assignment and define its description, deadline, team-size limits, and grading criteria.

Assignments begin as drafts. They become visible to students only after publication, allowing the instructor to prepare requirements before sharing them.

The instructor can then review teams and their submissions, prepare evaluations, and publish results when they are ready.

Separating “saved” from “published” is an important part of the workflow. Saving an evaluation should not automatically make an unfinished grade visible to students.

The instructor can define assignment requirements, deadlines, team sizes, and grading criteria.

The Student Workflow
Students can browse published assignments, create a team, or join an existing team using an invitation code, subject to the assignment’s rules.

Inside a team, members can organize tasks and track their status. Team leaders have additional controls for managing membership and assigning responsibilities.

For submissions, we chose project links rather than file uploads. The platform keeps submission versions, preserving the history when a team submits an updated version of its work.

Students can view their evaluation after the instructor publishes it.

Our Technology Stack
We used TypeScript across the frontend and backend.

Area Technology
Frontend React and Vite
Styling Tailwind CSS
Routing React Router
Server-state management TanStack Query
Backend Node.js and Express
Database PostgreSQL
Database access Drizzle ORM
Input validation Zod
Authentication Replit Auth
Automated testing Vitest and Supertest
The interface is in Arabic and uses a right-to-left layout.

TypeScript helps make the relationships between users, assignments, teams, tasks, and evaluations more explicit. However, compile-time types do not validate incoming HTTP requests, so the backend also checks input at runtime.

How the Application Fits Together
The application follows a frontend–backend–database structure:

React Interface
|
v
Express API
|
v
PostgreSQL Database

The frontend handles navigation, forms, and displaying information. The API validates requests, checks permissions, and applies the course’s rules. PostgreSQL stores the application’s persistent data.

This separation matters because the interface should not be responsible for enforcing rules that protect other users’ information.

Authentication: A Decision We Changed
Our original authentication choice was Clerk, but configuring external credentials became a barrier to trying the application.

We temporarily used an explicit development-only demo mode. Later, we chose Replit Auth, allowing users to sign in with their Replit accounts.

After enabling real authentication, we disabled the demo mode.

We also manually tested signing in and out, checking that users reached the correct dashboard and remained signed in after refreshing the page.

One important distinction became clear: a demo account selector can help demonstrate a workflow, but it is not a replacement for real authentication.

Permissions Belong on the Server
Hiding a button does not secure the action behind it.

A student should not be able to access another team’s information by changing a URL or sending a request directly to the API. Similarly, an unpublished evaluation should remain unavailable even if someone guesses its address.

For this reason, the backend checks the user’s role and, where relevant, team membership and leadership.

The interface guides users toward permitted actions. The server enforces those permissions.

Working with Replit Agent
We want to be transparent about how the project was built: Replit Agent wrote the application code based on the requirements and decisions we discussed.

Our role was to choose the problem, define the expected behavior, discuss alternatives, review the results, and try the application ourselves.

This still required specific decisions:

When should students be allowed to join a team?
What happens after an assignment’s deadline?
Who can manage team members?
Should saving an evaluation immediately reveal it?
How should updated submissions be recorded?
These questions shape the application regardless of who writes the code.

Using an AI coding assistant did not remove the need for clear requirements. It made those requirements especially important, because vague instructions can produce behavior that looks reasonable but does not match the intended rules.

Testing the Important Boundaries
We combined automated checks with manual testing.

The automated tests cover areas such as permissions, team rules, sessions, and authentication failures. Authentication tests include cases involving modified login data, expired login flows, and reused authorization codes.

There is also a successful authentication case, so rejected requests are not mistaken for evidence that security checks work when the entire login flow is actually broken.

Manual testing complemented these checks by letting us experience the application through the interface.

Passing tests does not guarantee that an application has no bugs. It does provide repeatable checks for specific behaviors that matter.

Keeping the Scope Manageable
We deliberately focused the current version on one course and its project workflow.

We did not include chat, file uploads, or AI features inside the product. Replit Agent was a development tool, not a feature of the platform itself.

Possible future improvements include:

Support for multiple courses.
Notifications for deadlines and published evaluations.
Additional progress reports for instructors.
Session management across multiple devices.
These are potential extensions, not features we claim are already implemented.

Final Thoughts
This project brought together several important parts of web development: authentication, authorization, relational data, validation, teamwork workflows, and testing.

Replit Agent helped us turn our requirements into working code. Our responsibility was to decide what the application should do, review its behavior, and test the result.

The most useful part of the project is not any individual screen. It is the connected workflow—from publishing an assignment to forming a team, submitting work, and receiving an evaluation.

For us, that made the project a practical way to explore how a full-stack application supports a real process, rather than simply displaying information.

DEV Community: Eng-younesAsaad

Building an Arabic Student Project Platform with Replit Agent