A stock-management portal built the way institutions actually need software built: from stakeholder requirements, not a template
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.
Academic delivery · Visual evidence pending
Why the project mattered
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 — the kind of discipline institutional software actually needs, even when it's less visually interesting than a product with a marketing site.
My role and ownership
- Stakeholder requirements analysis
- Merise data modelling
- The Laravel backend and Blade interface
- Functional testing
- Documentation and handoff
Personal contribution
Full solo ownership of requirements, modelling, implementation, testing and documentation across the internship.
The operational pain
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 — which is exactly the kind of gap an administrative audit finds, and exactly the kind of problem that erodes trust in a system faster than any UI issue would.
Before
- Manual or fragmented product records
- Stock levels checked reactively
- Movement history difficult to reconstruct
- Reports assembled separately, by hand
- Limited administrative visibility
After
- Centralized product and stock records
- Entry and exit movement history
- Automatic threshold-alert logic
- Excel and PDF exports generated from the same data an administrator sees on screen
- Documented institutional workflow
How the system works
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.
Architecture and decisions
Laravel, PHP, MySQL and Blade in a straightforward MVC structure — the standard, unglamorous stack, chosen deliberately for an institution that needs long-term maintainability over novelty, and where a future maintainer with ordinary Laravel experience should be able to pick this up without a learning curve I imposed for my own convenience.
Model movement history explicitly
Inventory must remain explainable through recorded entries and exits rather than only a mutable quantity field nobody can audit after the fact.
Thresholds as an operational control
Administrators need an early warning built into the system, instead of discovering a shortage only when someone requests the item.
Formal export formats
Excel supports further analysis; PDF supports stable administrative circulation that can't be accidentally edited downstream.
Document the complete lifecycle
Institutional adoption depends on requirements, testing and documentation as much as on the code itself — so all three were treated as deliverables, not afterthoughts.
Evidence that can be inspected.
An honest evidence map, not a screenshot gallery — this is the one project here without recovered interface captures.
Value and honest current state
Operational impact
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–May 2025 internship.
Verified evidence
Current limitations
This is the one project in the set with no recovered screenshots and no available source archive for this portfolio, and I'm not dressing that up: it should currently read as a strong CV line and a well-documented delivery, not a sixth full visual case study. It becomes one the moment dashboard, movement, alert and export captures are recovered — until then, I'd rather under-claim it than pad it with prose the evidence doesn't support.
Need software built for institutional continuity?
Requirements gathered with real stakeholders, modelled before implementation, and documented for whoever maintains it after you.