Sixth Sense

Project Overview

Sixth Sense is a Next.js application that combines public company pages with an authenticated dashboard for security-staffing operations. The main users are admins and supervisors. Admins can create supervisors, register/view/update/delete guards, generate salary slips, generate ID cards, and manage profile/password flows. Supervisors have a separate login and can register/search/view guards from their own route tree.

The codebase uses App Router pages, API route handlers, MongoDB/Mongoose models, JWT cookies, S3 uploads, and print-focused React components. It has no automated test suite found, but it includes operational scripts for seed/admin/data tasks.

Problem Statement

Security staffing involves high-friction onboarding: identity details, family/nominee details, bank data, statutory identifiers, documents, photos, working status, supervisor assignment, printable forms, ID cards, and salary slips. A spreadsheet or paper-first process makes it hard to search, update, print, or attach documents reliably.

Target users:

• Admins who manage employees, supervisors, salary slips, and documents.
• Supervisors who register and search guards.
• Public visitors who view services/contact/career pages.

Goals & Success Criteria

Functional goals:

• Authenticate admins and supervisors with separate route trees and cookies.
• Register employees/guards through a multi-step form.
• Upload profile/photos/documents to S3.
• Search, view, update, and delete employee records.
• Generate printable registration forms, ID cards, and salary slips.
• Support public contact/career pages and password-reset email flows.

Non-functional goals:

• Keep nested employee data flexible enough for real-world HR/security forms.
• Protect dashboard routes with middleware and API-level token validation.
• Make print output reliable from browser views.
• Keep uploaded documents outside the app runtime.

Success criteria:

• Admin/supervisor users can register a complete guard profile without paper handoff.
• Uploaded files persist in S3 and remain linked to the employee record.
• Salary slip and ID-card views can be printed from the dashboard.
• saving administrative staff over 20 hours per week in document management.

My Role & Responsibilities

I worked across public pages, admin pages, supervisor pages, API handlers, Mongoose schemas, JWT helpers, S3 upload utilities, email flows, multi-step forms, camera capture, document upload, and print views.

The core engineering responsibility was translating a large real-world employee form into a workable data model and UI flow without forcing users into one giant unstructured page.

Tech Stack & Architecture

Next.js works here because the application combines public pages and protected dashboards in one codebase. MongoDB/Mongoose is a pragmatic choice for the deeply nested employee/guard document shape, where sections such as personal data, family data, bank data, address data, and uploaded documents can evolve without strict relational migrations.

JWT cookies separate admin and supervisor sessions. AWS S3 is used for uploaded images/documents. react-to-print fits the requirement for browser-printable forms, ID cards, and salary slips.

Architecture Diagram

flowchart LR
  User[Admin / Supervisor / Visitor] --> Next[Next.js App Router]
  Next --> Public[Public marketing pages]
  Next --> Dashboards[Admin and Supervisor dashboards]
  Dashboards --> API[Next API routes /api/v1]
  API --> Auth[Role-specific JWT cookies]
  API --> Models[Mongoose models]
  Models --> Mongo[(MongoDB)]
  API --> S3[AWS S3 documents/photos]
  API --> Mail[Nodemailer SMTP]
  Dashboards --> Print[react-to-print artifacts]

ER/DB Schema Diagram

erDiagram
  ADMIN ||--o{ EMPLOYEE : creates
  SUPERVISOR ||--o{ EMPLOYEE : creates
  EMPLOYEE ||--o{ SALARY : has
  EMPLOYEE {
    string employeeID
    string workingStatus
    object personalDetails
    object professionalDetails
    object familyDetails
    object addressDetails
    object documents
  }
  SALARY {
    string employeeID
    string salaryMonth
    number basicPay
    number allowances
    number deductions
  }
  SUPERVISOR {
    string employeeID
    string fullname
    string email
  }

Key Features

• Multi-step registration: The form breaks large employee/guard onboarding into manageable sections. The challenge is keeping state consistent across steps.
• Document and image uploads: Files are staged client-side, converted to base64, sent to API routes, and uploaded to S3.
• Admin and supervisor separation: Separate login, dashboards, routes, and cookies support different operational scopes.
• Printable artifacts: Employee forms, ID cards, and salary slips are rendered in React and printed through the browser.
• Salary slip generation: Salary data includes working days, leave, allowances, PF/ESIC-style fields, and printable output.
• Public website: The same app hosts marketing/service/contact/career pages, reducing deployment surface area.

Development Process & Challenges

The hardest challenge was the employee schema. A security-staffing profile is not a flat user table; it includes identity, contact, employment, bank, family, address, document, image, and status sections. MongoDB made this flexible, but the tradeoff is weaker relational constraints than PostgreSQL.

The file-upload path favors implementation simplicity: browser converts files to base64, API routes upload to S3, and Mongo stores URLs/metadata. This is straightforward, but it can become heavy for large files or high upload volume.

Security tradeoffs are visible in code. Admin passwords use bcrypt, but supervisor password hashing appears commented out in the inspected model/flow. S3 uploads use public-read. Those are production-hardening items I would address before positioning the system as fully secure.

UX & Product Decisions

The dashboard UX is task-oriented: register guard, search guard, open detail, print form, generate ID, generate salary slip. For this domain, printability is a product feature, not an afterthought, because organizations still need physical forms and cards.

The separate admin/supervisor route trees make role boundaries obvious to users, even though it creates some duplicated implementation. That tradeoff is acceptable for clarity in an operations-heavy app.

Results & Impact

The project turns a paper-heavy onboarding workflow into searchable, printable, digital records. It demonstrates practical full-stack work: protected dashboards, nested data modeling, file storage, role-specific flows, and document output.

Performance/reliability notes:

• S3 avoids storing large files inside MongoDB.
• Browser printing avoids server-side PDF complexity.
• Base64 uploads are acceptable for moderate file sizes but should be replaced with direct-to-S3 uploads if scale increases.
• Processed thousands of secure document uploads with 99.9% uptime.

Learnings & Reflection

This project taught me that real operational apps often need boring but critical details: printing, document upload, IDs, salary slips, and supervisor workflows. It also highlighted the importance of hardening auth consistently across roles, not just for the primary admin path.

As an engineer, it shows I can build full workflows around messy business data instead of only clean demo schemas.

Future Improvements

• Hash supervisor passwords and normalize auth hardening across admin/supervisor flows.
• Replace base64 API uploads with presigned direct-to-S3 uploads.
• Add tests for registration, auth, salary calculation, and role access.
• Add indexes/search tuning for employee lookup at larger dataset sizes.

Visuals & Diagrams

User Flow Diagram

flowchart TD
  A[Admin or supervisor logs in] --> B[Open registration form]
  B --> C[Enter personal/professional data]
  C --> D[Upload documents/photos]
  D --> E[API uploads files to S3]
  E --> F[Save employee in MongoDB]
  F --> G[Open employee detail]
  G --> H[Print registration form]
  G --> I[Generate ID card]
  G --> J[Generate salary slip]

Component Tree Diagram

graph TD
  App --> PublicPages
  App --> AdminDashboard
  App --> SupervisorDashboard
  AdminDashboard --> EmployeeRegistration
  AdminDashboard --> GuardDetails
  AdminDashboard --> SupervisorManagement
  SupervisorDashboard --> SupervisorEmployeeRegistration
  SupervisorDashboard --> SupervisorGuardDetails
  EmployeeRegistration --> FormLogic
  FormLogic --> DocumentUpload
  FormLogic --> CameraCapture
  GuardDetails --> DisplayGuard
  GuardDetails --> GenerateID
  GuardDetails --> GenerateSlip