Device License & AMC Management Platform

Industry

IT asset · software entitlement · vendor AMC

Type

Enterprise lifecycle web app + REST / external APIs

Roles

Administrator · Customer (scoped)

Stack

Next.js 15 · NestJS · MongoDB 7 · Mongoose · Docker

Focus

Identity → assets → entitlements → AMC → alerts → integrations

Proof

6 UI screens · architecture diagrams · API surface map

Project overview

The platform replaces fragmented tracking of devices, software entitlements, maintenance contracts, expiry dates and ownership information with a unified system of record. It provides:

• Centralized device management and status synchronization
• Software license lifecycle management and usage tracking
• Annual Maintenance Contract management as a first-class domain
• Role-based access control (administrator vs customer scope)
• Dashboard analytics, expiry/compliance alerts and notification management
• External system integration APIs and license validation APIs
• Audit/activity tracking, PWA/mobile support and Docker-based deployment

Underlying architecture: Next.js frontend, NestJS backend, MongoDB data layer, with JWT authentication, RBAC, API validation, security controls and containerized infrastructure.

The business challenge

Organizations often manage IT assets and software entitlements across spreadsheets, databases, emails, procurement records and vendor portals. That creates four operational failure modes.

1. Device information becomes fragmented

IT teams need a reliable answer to: which devices exist, who owns or uses each one, where it is, what hardware it has, when it was purchased, when warranty expires, and whether it is active, inactive, under maintenance or retired. Without a centralized registry, audit and day-to-day ops both suffer.

2. Software licenses are difficult to track

Licensing has its own lifecycle: Purchase → Assignment → Usage → Renewal → Expiry. Teams need visibility into keys, vendors, license type, dates, assigned devices/users, purchased vs used seats, status, cost and currency. The platform models these attributes directly in the license domain.

3. AMC renewals can be missed

Annual Maintenance Contracts carry commercial and SLA implications — contract number, covered device, vendor, type, period, renewal date, cost, coverage, response time, contacts and status. AMC is treated as a first-class business domain, not a note stuck on a device record.

4. External systems need access to the data

A management desk becomes far more useful when other applications can register devices, validate licenses, check AMC, update status/usage and query device information. That requires a dedicated external API layer with API-key authentication — separate from human JWT sessions.

Project objectives

• Centralize asset information — one operational view of devices, users, licenses and maintenance contracts.
• Improve lifecycle visibility — warranty, license and AMC expiry, renewal dates, device status and license utilization.
• Automate compliance awareness — dashboard alerts and notification mechanisms for upcoming expirations.
• Establish controlled access — administrators and customers operate within defined boundaries.
• Provide integration capabilities — APIs for register, validate, synchronize and retrieve lifecycle information.
• Build a maintainable architecture — modular services, typed FE/BE, contracts, validation, security controls and containers.

Solution overview

A web-based management platform with three primary layers: Web / PWA client (Next.js · React · TypeScript · Tailwind / Bootstrap) → Application / API (NestJS · Auth · RBAC · domain modules · external APIs) → Data (MongoDB 7 · Users · Devices · Licenses · AMC · Notifications).

flowchart TB
  subgraph client [Web / PWA Client]
    UI[Next.js · React · TypeScript]
    SURF[Dashboard · Devices · Licenses · AMC · Users]
  end
  subgraph api [Application / API Layer]
    NS[NestJS · TypeScript]
    DOM[Auth · RBAC · Devices · Licenses · AMC · Users · Dashboard · Notifications · External APIs]
  end
  DB[(MongoDB 7)]
  UI --> SURF
  SURF -->|REST| NS --> DOM --> DB

Core product modules

1. Device management

The central asset registry. Each device can carry identity (unique ID, name, manufacturer, model, serial, type), operational status, location, assigned user/owner, hardware (CPU, memory, storage, OS, network), warranty and purchase/install dates, plus description/notes.

Categories: Laptop · Desktop · Server · Mobile · Tablet · Other. Lifecycle states: Active · Inactive · Maintenance · Retired.

flowchart TD
  R[Register device] --> A[Assign owner / user]
  A --> T[Track location and status]
  T --> L[Associate licenses]
  L --> M[Associate AMC]
  M --> O[Monitor lifecycle]

2. Software license management

Entitlement and usage records: license key, software name, vendor, type, status, start/end dates, cost/currency, assigned device/user, total vs used seats, description and notes.

Types: Perpetual · Subscription · Annual · Monthly. States: Active · Expired · Suspended.

flowchart TD
  P[License purchased] --> REG[Register license]
  REG --> ASN[Assign device / user]
  ASN --> SEAT[Track seat usage]
  SEAT --> EXP[Monitor expiry]
  EXP --> S1[Active / Expiring / Expired / Suspended]

3. Annual Maintenance Contract management

Dedicated AMC domain: contract number, covered device, vendor, AMC type, status, start/end/renewal dates, cost/currency, coverage, response time, contact person/email/phone, terms and notes.

Types: Hardware · Software · Comprehensive. States: Active · Expired · Pending · Cancelled.

Useful not only as an IT asset registry, but as a lifecycle-management platform for vendor-supported assets.

4. User management & RBAC

Administrators manage devices, licenses, AMC, users, system-wide dashboards and full CRUD across managed entities.

Customers operate in a restricted data scope: own devices, related licenses/AMC, permitted registration, customer-level dashboard — only authorized data.

5. Dashboard & operational visibility

Documented metrics include total/active devices, licenses and AMC contracts; total users; expiring licenses/AMC; offline devices; and revenue-style operational tiles where configured. The desk also surfaces recent activities and system alerts so admins see what changed and what needs attention.

flowchart TB
  DASH[Operations dashboard]
  DASH --> DEV[Devices — active / offline]
  DASH --> LIC[Licenses — active / expiring]
  DASH --> AMC[AMC — active / expiring]
  DEV --> AL[Alerts and activity]
  LIC --> AL
  AMC --> AL

6. Notification & alerting

Notification listing/create/update/delete, preferences, expiry alerts, email and push. Lifecycle events (license expiry, AMC renewal, device status) feed an alert engine that updates the dashboard and notification channels.

External API architecture

The platform is not isolated behind the web UI. Machine clients authenticate with:

X-API-Key: <your-api-key>

Separate from JWT used by application users.

Device registration

POST /api/external/register-device — validate request, identify owner, create device, return status. Accepts identity, manufacturer, model, serial, type, owner email, specifications, purchase date and warranty information.

License validation

GET /api/external/validate-license/:licenseKey — returns validity, software, vendor, status, end date, seat counts and license type so external apps can decide without admin UI access.

AMC status

GET /api/external/amc-status/:deviceId — whether an active AMC exists, contract number, vendor, end date, response time, contacts, type and coverage.

Device status & license usage sync

• POST /api/external/device-status — device ID, current status, last-seen, location
• POST /api/external/license-usage — license key, used seats, last-used timestamp

Webhooks

Event-driven integration for device.status.updated, license.usage.updated and amc.renewal. Device status webhooks can carry current and previous status so consumers react to lifecycle changes.

Data & API architecture

MongoDB collections include users, devices, licenses, amcs, notifications and notificationsettings. Application-level relationships: User → Devices → Licenses / AMC; User → Notifications.

REST domains: /auth, /devices, /licenses, /amc, /users, /dashboard, /notifications, /api/external/*, /webhooks/*.

Documented API concerns include pagination, filtering, sorting, versioning, standard status/error shapes and rate limiting — e.g. GET /devices?status=active&type=laptop&search=dell and sort=createdAt:desc.

Authentication, security & rate limiting

Human auth flow: login → credential validation → JWT → authenticated request → JWT validation → RBAC → business operation. Backend uses JWT, Passport, bcrypt, role-based authorization, token expiration and request validation.

Security controls

• Authentication — JWT, bcrypt hashing, token expiry, login rate limiting
• Authorization — RBAC, admin/customer separation, restricted customer scope
• API security — API keys for external routes, validation, response/error sanitization, rate limiting, audit logging
• Application security — CORS, Helmet headers, input validation, XSS/CSRF protections, HTTPS

Rate-limit headers expose X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Auth traffic and machine-to-machine traffic have different operational profiles — limits reflect that.

Frontend, backend, PWA & DX

Frontend

Next.js 15.5.2 · React 18 · TypeScript · Tailwind CSS · Bootstrap 5 · React Context · Axios · React Hook Form · date-fns · Recharts · React Hot Toast. Responsive UI, dashboard charts, forms, auth and PWA support.

Backend

NestJS · Node.js · TypeScript · MongoDB/Mongoose · JWT/Passport · class-validator · Swagger/OpenAPI · scheduled jobs · Helmet · bcrypt. Modules: Authentication, Users, Devices, Licenses, AMC, Notifications, Dashboard, External Integrations.

PWA

Offline support, cached pages, background sync foundation, push notifications, installable icons/splash and full-screen mobile-oriented workflows.

Developer experience

Interactive Swagger/OpenAPI docs with request/response examples, auth requirements and error codes; Postman collection for integration testing.

Deployment, environments, testing & ops

Docker Compose for MongoDB, NestJS backend and Next.js frontend. Environments: dev (hot reload, debug logging, open CORS) · staging (production build, limited logging, restricted CORS) · production (optimized builds, minimal logging, strict CORS).

Testing strategy

• Unit — services and components (Jest, React Testing Library)
• Integration — APIs, DB, auth (Supertest, MongoDB memory server)
• E2E — browser journeys (Playwright)
• Performance — load/stress in the overall plan

Documented targets: ~80% overall coverage, 100% on critical paths, full API endpoint coverage and complete user-flow coverage — treated as engineering goals, not inflated claims.

Monitoring & maintenance

Error/performance monitoring, activity logging, health checks; DB query/pool monitoring, backup/recovery and integrity checks. Regular security/dependency updates, DB optimization, SSL and backup verification.

Backup

mongodump / mongorestore for the data plane; Git, env configs, Docker images and certificates as application-level backup concerns.

Scalability considerations

Architecture allows load balancing across multiple backend instances, indexing/query optimization, caching and CDN for static assets. These are design considerations for growth — not a claim that every mechanism is live in every environment.

Engineering challenges & key decisions

The hard problem was not CRUD screens. The system had to connect related lifecycle domains:

flowchart TB
  U[Users] --> D[Devices]
  D --> L[Licenses]
  D --> A[AMC]
  L --> N[Notifications]
  A --> N

1. Maintain relationships between devices, users, licenses and contracts
2. Preserve access boundaries
3. Track lifecycle dates as first-class concepts
4. Expose selected data to external systems
5. Keep external auth separate from user JWT
6. Provide operational visibility and alerts
7. Stay maintainable as domains grow

Key architecture decisions

• Domain-oriented backend — clear modules, not one undifferentiated layer
• API-first integration — documented REST for app and machines
• Separate auth mechanisms — JWT vs API keys
• Explicit access boundaries — admin vs customer scopes
• Lifecycle-driven design — expiry, renewal, usage, status
• Containerized infrastructure — Docker for consistent deploys
• Documentation-driven DX — Swagger + Postman

Representative end-to-end workflow

flowchart TD
  SRC[External / internal source] --> REG[Device registration]
  REG --> REC[Device record]
  REC --> OWN[Assign user and location]
  OWN --> LA[License assignment]
  LA --> LU[License usage]
  LU --> AA[AMC assignment]
  AA --> MON[Lifecycle monitoring]
  MON --> EVT[License expiry / AMC renewal / device status]
  EVT --> ALERT[Alert / event]
  ALERT --> OUT[Dashboard + notification]

Technology stack

My role / solution architecture

End-to-end contribution across business-domain modeling, application/frontend/backend architecture, REST API design, authentication & RBAC, MongoDB modeling, external APIs & webhooks, notification architecture, PWA, security, Docker deployment, testing strategy, scalability planning and ops considerations.

Focus was connecting the complete operational lifecycle into one coherent system — not shipping isolated screens or endpoints.

Architecture principles

1. API-first integration (no direct DB coupling for externals)
2. Separation of concerns across FE, services, data, auth, notifications and integrations
3. Security by design
4. Lifecycle awareness for assets and entitlements
5. Extensibility without full redesign
6. Operational visibility as a first-class concern

Business value & architectural significance

The documented capabilities help organizations establish a single source of truth, improve lifecycle visibility, reduce manual tracking, support ops teams with dashboards/alerts, integrate via APIs/webhooks, control access to sensitive ops data and leave room for future expansion (discovery, provisioning, vendor/procurement, multi-org, richer observability).

Architecturally, this is not “device CRUD + license CRUD + AMC CRUD.” It connects:

Identity → Assets → Software entitlements → Maintenance contracts → Lifecycle events → Notifications → External integrations

That model answers operational questions through one system: active devices, owners, assigned licenses, seat usage, approaching expiry, AMC coverage, recent changes and which external systems need status updates.

Screenshots

Login — admin & customer demo planes

JWT login with separate demo paths for administrator and customer roles — matching the RBAC split in the backend.

Admin dashboard — KPIs, alerts, activity

Operational tiles for devices, active licenses, AMC contracts and users, plus compliance alerts for expiring licenses/AMC and offline devices.

Devices — registry & lifecycle status

Filterable device list with type, owner, location, warranty and active / maintenance / inactive states.

Licenses — seats, type, expiry

Seat utilization and expiry visibility across subscription, annual, monthly and perpetual license types.

AMC — contracts & renewals

AMC rows carry vendor, covered device, contract type, renewal date and active / pending / expired status.

Users — administrator vs customer scope

Administrators manage the estate; customers stay inside authorized device/license/AMC counts.

Architecture at a glance

flowchart TB
  subgraph clients [Clients]
    WEB[Next.js PWA]
    EXT[External systems]
  end
  subgraph api [NestJS API]
    JWT[JWT + RBAC]
    KEY[API-key external APIs]
    DOM[Devices · Licenses · AMC · Users · Notifications · Dashboard]
    WH[Webhooks]
  end
  DB[(MongoDB 7)]
  WEB --> JWT --> DOM
  EXT --> KEY --> DOM
  DOM --> WH
  DOM --> DB

Outcomes & project highlights

• Single operational view for devices, licenses and AMC instead of disconnected sheets
• Clear admin/customer access boundaries with dashboard and scoped customer desks
• Integration-ready external APIs for registration, validation, AMC query and status/usage sync
• Lifecycle-driven design with expiry alerts and notification preferences
• Documented security, rate limits, Docker deployment, Swagger/OpenAPI and testing strategy
• Foundation for future extension (discovery, procurement, multi-org, richer observability) without rewriting the core model

Portfolio write-up documents shipped architecture and UI evidence; it does not invent revenue, uptime or “every scaling feature is live” claims. Future extension areas are possibilities, not current feature lists.

FAQ — buyer & architecture questions

Ten common questions about this case study, fit, and engagement.