Published / updated29 Aug 2026

Guided Full-Stack Project

Before you start

You need: stages 1 to 8. This is where they connect.

Time: six weeks at a steady pace. Build one vertical slice first, then widen it.

Learning objective

Build one complete School Management System feature through every layer, working the way a team works.

Topics

• Choosing and scoping the project
• The required end-to-end flow
• Project structure
• Working in verified increments
• The rules that must hold at every layer
• Definition of done

What this stage covers

Everything from stages 1 to 8, on one application. No new concepts — this is where they connect.

The syllabus offers Student Management, Employee Management or Inventory Management as mini projects. Build Student Management — it is the domain this whole curriculum has used, so you already have the schema, the entities and the worked examples.

Scope it tightly. One module built completely beats four built partially. A working fee module with authentication, validation, tests and a receipt is a portfolio piece; four half-finished modules are not.

Required flow

The application must demonstrate one complete vertical slice:

Browser (Angular or React)
   │  a form, a list, a detail screen
   ▼
ASP.NET Core Web API
   │  JWT, validation, DTOs, status codes
   ▼
Service layer
   │  the business rules
   ▼
Dapper repository
   │  parameterised SQL, transactions
   ▼
SQL Server
      normalised tables, constraints, stored procedures

Required features

#	Feature	Demonstrates
1	Sign in, receive a JWT	Authentication
2	Student list, filtered to the signed-in school	Multi-tenancy
3	Search by roll number and name	Filtering, indexing
4	Add a student, rejecting duplicates	Validation, composite uniqueness
5	Record a fee payment	Transactions, decimal
6	Print a fee receipt	The worked flow, end to end
7	Enter exam marks, including absent	Nullable handling
8	Class result report	Grouping, aggregation, absent exclusion
9	Role-based access	Authorisation

Feature 9 is not optional. A Teacher must not reach the salary report or another school's students, and you must be able to demonstrate the 403.

Project structure

NexCoding.SchoolPortal/
├── src/
│   ├── NexCoding.SchoolPortal.Api/         controllers, middleware, Program.cs
│   ├── NexCoding.SchoolPortal.Core/        entities, enums, interfaces
│   ├── NexCoding.SchoolPortal.Data/        Dapper repositories
│   └── school-portal-web/                  Angular or React
├── database/
│   ├── 01-schema.sql
│   ├── 02-procedures.sql
│   └── 03-seed.sql
├── tests/
│   └── NexCoding.SchoolPortal.Tests/
├── CLAUDE.md                                project rules for AI assistance
├── CONTRIBUTING.md                          branch and commit conventions
├── ENVIRONMENT.md                           setup checklist
├── RUNNING.md                               how to run it
└── README.md

Four documents, not one. RUNNING.md is the one a new developer opens first, and the test of it is whether they reach a running application without asking you anything.

Worked flow: the fee receipt, complete

The feature this path has followed since stage 1, now in all five layers:

Layer	Artifact	Rule it enforces
Database	usp_GetFeeReceipt, UNIQUE (SchoolId, StudentId, AcademicYear)	DECIMAL(18,2); one account per student per year
Repository	FeeRepository.GetReceiptAsync(schoolId, paymentId)	Parameterised; SchoolId filtered; connection in using
Service	FeeService builds the DTO, generates the receipt number	Balance calculated once, here
API	GET /api/fee-payments/{id}/receipt	schoolId from the claim; [Authorize(Roles=...)]; returns a DTO
Frontend	Receipt component with a print stylesheet	Loading, 401, 404 and 500 handled separately

Run it for Ravi Kumar (NCA-2024-0012) at NexCoding Academy, whose two FeeAccount rows are the case that broke it in stage 8.

Trace one request through all five and you can explain your project in an interview. That is the actual deliverable of this stage.

Working in increments

Build the vertical slice first, then widen it.

Week 1   Sign-in and the student list, end to end
Week 2   Add student, search, validation
Week 3   Fee payment and receipt
Week 4   Exam marks and the class report
Week 5   Roles, error handling, tests
Week 6   Documentation, deployment build, presentation

One thin slice through all five layers in week 1 beats a complete database in week 1. It proves the layers connect, surfaces the CORS and token problems immediately, and every later feature reuses the plumbing.

Commit each verified increment. git status clean, build, test, commit. Stage 8's habits apply here.

The rules that must hold

These are the correctness themes this curriculum has threaded through every track. Every one produces a wrong result with no error message.

Rule	Where it must hold
SchoolId from the token, never the request	API, and every WHERE clause
Every read excludes soft-deleted rows	Every repository method
UNIQUE (SchoolId, RollNumber), never RollNumber alone	Database
decimal and DECIMAL(18,2) for money	Every layer
Absent marks are NULL, never 0	Database, entity, service, DTO
The absent check comes first	Every grading chain
Every command inside a transaction receives it	Repository
Server-side validation, always	API
Authorisation on the server, not the button	API

Print this list and check your project against it before you call the project done.

Definition of done

• All nine features work end to end
• A user of School 1 cannot retrieve School 2's data — demonstrated from Postman
• A Teacher receives 403 on an Admin-only endpoint — demonstrated from Postman
• Client-side validation is bypassed from Postman and the API still rejects it
• A duplicate roll number is rejected at the API and by the database constraint
• An absent student shows Absent, is counted, and is excluded from the average
• Recording a payment rolls back cleanly when the second statement fails
• Money is decimal end to end — no double or FLOAT anywhere
• Every endpoint returns the correct status code, including 400, 401, 403 and 404
• Unhandled exceptions log fully server-side and return a generic message
• No secret in the repository — git log -p | grep -i password returns nothing
• Unit tests for the grading logic and the fee calculation, each failing without its fix
• RUNNING.md gets a new developer to a running application unaided
• Every commit is on a branch with a pull request

Practice

1. Choose Student Management and write its scope — what is in, what is explicitly out.
2. Build the vertical slice in week 1: sign in, student list, all five layers.
3. Add the remaining features one at a time, committing each verified increment.
4. Demonstrate the cross-school 403 from Postman and record the response.
5. Demonstrate the Teacher 403 on an Admin endpoint.
6. Bypass the frontend validation from Postman and confirm the API rejects it.
7. Record a payment where the second statement fails, and confirm nothing was written.
8. Enter marks for a class with five absent students and check the average against a hand calculation.
9. Search with SET STATISTICS IO ON, add the index, and record the logical reads before and after.
10. Write RUNNING.md and have someone else follow it on a clean machine.
11. Run the full rules checklist above against your project and fix everything it finds.

Exercises 4 to 8 are the evidence. Screenshots of them belong in your submission.

You can now

• Build one feature through all five layers
• Enforce the nine rules that fail with no error message
• Demonstrate cross-school isolation and role restrictions from Postman
• Work in verified increments on branches
• Write documentation another developer can follow

Review questions

1. Why build one thin vertical slice before completing any single layer?
2. Which of the nine rules produce wrong results with no error message?
3. How would you demonstrate that a School 1 user cannot read School 2's data?
4. What makes RUNNING.md complete?

Next: Test, deploy, and explain