Recent activity
Show the latest exercises and provide a clear next action when no activity is available.
Case study · Aug–Dec 2025
OWARU
I connected a Next.js interface to an existing Django and PostgreSQL system, delivered a functional student dashboard and translated system-dynamics research into three working simulations.
Overview
Product context and challenge
OWARU is an educational technology platform that combines interactive project-management exercises, system dynamics, feedback and progress tracking.
My work sat at the boundary between product development and applied research: understanding an existing data model, exposing useful backend data, shaping it into frontend workflows and turning simulation models into usable learning activities.
Core challenge
The product already had Django models and relationships that the new dashboard needed to respect. I first had to understand that structure well enough to expose real data without disrupting the surrounding system.
The simulation work was the most difficult part. I was unfamiliar with the modelling approach, and each scenario had to translate interconnected variables and calculations into results that matched the case being simulated.
Role
My scope within the team
I worked as a full-stack developer within a multidisciplinary team of approximately 10 people, supported by one tutor. I collaborated with frontend, backend and simulation developers and participated in planning, reviews and demos.
- Analyze existing Django and PostgreSQL models and relationships
- Build backend functions for the student dashboard
- Integrate Next.js interfaces with Django endpoints
- Define and adapt schemas and payloads across the integration boundary
- Build recent-exercise, calendar, assessment and progress interfaces
- Create the exercise-feedback interface and unify component styling
- Research and apply Apache ECharts
- Research system dynamics and define simulation variables and scenarios
The functional interactive dashboard and the simulation activities were team outcomes. The responsibilities listed here describe the work I completed personally within that shared effort.
Architecture
How the product layers connected
Student interface
Next.js and React surfaces for dashboard activity, feedback and simulation results.
Integration layer
REST requests and adapted payloads connecting product workflows to backend data.
Application logic
Django functions and domain rules supporting dashboard and exercise flows.
Data layer
Existing PostgreSQL models and relationships used as the system of record.
Workflow
A dashboard organized around student progress
Monthly calendar
Place learning activity in a simple month-level view alongside the rest of the dashboard.
Assessment status
Surface the latest evaluation and score using data supplied by the backend.
Progress and feedback
Visualize completion progress and connect students with the exercise-feedback flow.
Contribution
Work completed across the stack
Backend and data
- — Analyzed Django and PostgreSQL relationships
- — Implemented backend functions for dashboard data
- — Defined and adapted schemas and payloads
Frontend and integration
- — Built recent-exercise, calendar, assessment and progress components
- — Connected Next.js workflows to Django endpoints
- — Displayed real application data in the interface
Product interface
- — Unified styles and reusable components
- — Implemented the exercise-feedback interface
- — Researched and applied Apache ECharts for results
Simulation research
- — Studied the existing system-dynamics models
- — Defined variables and scenarios
- — Implemented three simulations demonstrated in the product
Decisions
Technical choices shaped by an existing system
Understand the existing model before extending it
I began by tracing Django and PostgreSQL relationships so new dashboard functions could work with the existing domain structure.
Treat payloads as an explicit integration boundary
Schemas and payloads were defined or adapted so Next.js components received predictable data from Django.
Use Apache ECharts for simulation feedback
I applied ECharts to translate calculated time-series results into visual feedback inside each exercise.
Use existing diagrams as the implementation guide
After finding no suitable replacement tool, I analyzed the pre-existing system-dynamics diagrams to determine a viable development path.
Deep dive
From unfamiliar models to three working simulations
Challenge
Each scenario depended on a modelling approach I had not previously used, with many connected variables influencing the final result.
Approach
I studied the existing diagrams, mapped their relationships into an implementation path and connected the calculated output to the interface.
Result
Three simulations were running successfully and were prepared and demonstrated as reinforcement activities.
01
Basic Design
Capacity, defect detection and correction influence rework and design quality.
02
Customer Demand
Backlog, order fulfilment, delivery delay and cancellations evolve over time.
03
Detail Design
Design speed, capacity, defects and final quality must be balanced.
Outcome
What shipped—and what remains unproven
3simulations running successfully
Delivered
- Functional student dashboard
- Integrated frontend and backend workflow
- Real product data rendered in dashboard components
- More consistent interface and component styling
- Three simulation scenarios prepared and demonstrated
- First functional integrated version
Limitations
- The work did not reach a formal testing stage, so there are no additional verified performance or learning metrics to report.
- No controlled student pilot or measured educational outcomes are claimed in this case study.
- This page documents my contribution to a team product rather than sole ownership of the complete platform.
Lessons
- Working inside an unfamiliar system required understanding its existing relationships before attempting to change the implementation.
- Translating a system-dynamics diagram into software was a distinct engineering problem from explaining its output clearly in the product interface.
Evidence
Selected product evidence
Dashboard overview
The integrated dashboard combines recent activity, calendar, evaluation, feedback and progress in one workflow.
Simulation 01 · Basic Design
Full resolutionA complete exercise moving from scenario context and variables to calculated results and time-series charts.
Simulation 02 · Customer Demand
Full resolutionA customer-demand scenario connecting production decisions with backlog, delivery delay and cancellations.
Simulation 03 · Detail Design
Full resolutionA detailed-design scenario exploring speed, rework and quality through adjustable variables and visual output.
Supporting interface
Full resolutionA supporting account flow showing how the product visual language extends beyond the dashboard.
Attribution
Team work, clearly attributed
OWARU was developed by a multidisciplinary team of approximately 10 people with one tutor. Product names and interface imagery are shown with permission. Proprietary source code, schemas, equations and parameter sets are not reproduced.