Full Stack Portfolio Project: Build a Simple Enquiry Tracker in Nagpur
Use a fictional enquiry tracker to practise front end, APIs, databases, validation and access controls in one manageable full stack project.
A full stack portfolio should demonstrate how a user action becomes a reliable change in stored data. A small enquiry tracker is a practical exercise because it connects forms, business rules, a database and a clear interface. Learners considering full stack development in Nagpur can use this brief to judge their progress.
Build it with fictional records only. The project is a learning example, not a request to copy student information or connect to IT Accurate’s operational systems.
Specify the smallest useful version
Allow a user to create an enquiry, choose a course interest, set a follow-up date and record a status. Show a list with filters for course and status. Keep the initial status choices simple: New, Contacted, Demo requested and Closed.
Write down what each status means. A “Contacted” record should not be counted as an admission. Clear definitions are part of application design because users need consistent meaning behind the labels.
Design the data before styling the screen
Give each enquiry a stable identifier. Store notes separately if you want a history of multiple follow-ups. Record timestamps and define the timezone used for display. Use a separate list of allowed course names so spelling variations do not create accidental categories.
Sketch how the form, API and database interact. Explain which values the user supplies and which the server controls. Do not trust a browser field to decide which user owns a record.
Validate on both sides
Browser validation can provide quick feedback, but the server must validate submitted data too. MDN’s form guidance explains why client-side validation can be bypassed. Check required fields, accepted status values and the expected date format on the server.
Return clear errors near the relevant field. Preserve the user’s non-sensitive input after a validation failure so they do not have to start over. Prevent repeated clicks from accidentally creating multiple copies of the same enquiry.
Add access rules and a change history
For a second stage, introduce two fictional staff accounts. Decide whether each can view all records or only assigned ones, and enforce the rule on every API request. Hiding an edit button in the interface is not an access-control mechanism.
Keep a history of status changes with the actor and time. Use appropriate password handling through an established authentication approach; do not store plain-text passwords. Keep secrets outside the repository.
Test the complete journey
- Create a valid enquiry and confirm it appears once.
- Submit an invalid status and confirm the server rejects it.
- Edit a record and verify that filters still behave correctly.
- Try to access another account’s restricted record.
- Check keyboard navigation, field labels and a narrow mobile screen.
- Show a useful error when the server is temporarily unavailable.
Present a short demonstration, a database diagram and setup instructions. Explain one bug you found and how you verified the fix. This makes your contribution easier to assess than a screenshot of a finished page alone.
Explore the Full Stack Developer course and contact the Nagpur branch to confirm the current technology track, prerequisites and batch mode. Contact us for fees.