06 / INSTITUTIONAL PROJECT

Centralizing institutional stock movements, threshold alerts and reporting

A Laravel inventory portal built from administrative requirements to centralize products, movements, low-stock alerts and formal reporting.

STATUS	Academic delivery · Visual evidence pending
TEAM	Solo internship project
DEMO	Demo pending source recovery
SOURCE	Source not currently published

Executive Summary

During a final internship at Faculté Chariaa in Fès, I built a stock-management portal directly from requirements gathered with administrative stakeholders — the kind of engagement where continuity and traceability matter more than visual polish, and where the requirements-gathering itself is half the engineering work.

Context

A public university environment, where a stock system has to survive staff turnover and produce reports that satisfy an administrative audit trail, not just look good in a demo. Between February and May 2025, I worked directly with administrative stakeholders to define the requirements before writing a line of code.

My role and ownership

• Stakeholder requirements analysis
• Merise data modelling
• Laravel backend and Blade interface
• Functional testing
• Documentation and handoff preparation

Personal contribution

Requirements, modelling, implementation, testing and documentation.

Problem

Manual stock checking meant nobody could answer "how much do we actually have" without walking to the shelf. Low-stock situations were caught late because nothing was watching thresholds. And there was no single, reconstructable history of what entered and left inventory — exactly the kind of gap an administrative audit finds.

Solution

Products and movements share one relational core, modelled with Merise before a line of code was written and reviewed with the stakeholder group so the data model was agreed on, not just assumed. Configurable thresholds trigger alerts when stock drops below a set level per product, rather than relying on someone remembering to check manually.

Every movement — entry, exit, adjustment — writes to a history that Excel and PDF reports generate from directly, so a printed report reflects the same data an administrator would see on screen, not a separately maintained summary that can quietly drift out of sync with reality. The lifecycle, step by step:

Engineering

The documented stack is Laravel, MySQL, Blade and MVC in a straightforward structure — the standard, unglamorous choice, deliberate for an institution that needs long-term maintainability over novelty. Requirements and data relationships were modelled with Merise before implementation began.

Outcome

The delivered system gave the institution centralized product records, a reconstructable movement history, automatic low-stock alerts, and reports generated straight from the operational data instead of assembled separately — a complete requirements-to-documentation cycle over a February to May 2025 internship.

Verified evidence

• CV documents the internship, stack and complete delivery cycle
• Threshold alerts, movement history and Excel/PDF exports are consistently documented
• Requirements analysis and Merise modelling were part of the project
• Visual proof remains pending and is clearly disclosed

Current limitations

• No project screenshots were included in the supplied screenshot archive.
• No source archive or live runtime was supplied for independent verification.
• The project should not be presented as a final visual showcase until dashboard, movement, alert and export captures are added.
• No numerical impact is claimed without institutional measurement.

STATUS	Academic delivery · Visual evidence pending
TEAM	Solo internship project
DEMO	Demo pending source recovery
SOURCE	Source not currently published