Service landing page
The public starting view presents the service offer, main repair request CTA and consistent PRO-KOM branding.
💼 Business Solution
PRO-KOM Serwis System
A system for managing electronics repair workflows — from device intake, through diagnosis and status updates, to customer pickup. Inspired by 2.5 years of experience in a real service environment.
3
user panels
RBAC
permission system
8+
Celery async tasks
HTTPS
Let's Encrypt
Django 5.1DRFPostgreSQL 16Redis 7Celery 5.4Next.js 14TypeScriptTailwind CSSReact QueryZustandFramer MotionDockerNginxCertbotpytestGitHub Actions
ORIGIN
Problem I wanted to solve
I built this project from the perspective of someone who worked in an electronics service environment for 2.5 years. That helped me understand where information gets lost in the daily repair process, what slows down service work and what customers, staff and business owners actually need.
No self-service repair status
Customers had to call the service to ask what was happening with their device. The system solves this with a status panel, notifications and a clear repair history.
Manual service workflow management
The process relied on notes, spreadsheets and manually tracking priorities. The staff panel organizes repairs in a Kanban view with statuses, assignments and items that require action.
No single operational data view
The business owner needs quick access to repair times, technician workload, common issues, revenue and inventory status. The admin panel brings these data points into one place.
SCOPE
My role in the project
Individual project. Idea, architecture and implementation — built fully by me.
Domain modeling
I translated a real repair workflow into a Django data model: repair tickets, devices, customers, statuses, quotes, parts, change history and repair lifecycle.
Three user panels
I designed separate flows for customers, staff and administrators: self-service for customers, Kanban for staff and a management dashboard for admins.
Async tasks and notifications
I used Celery and Redis to handle notifications, automatic reminders, backups and tasks executed outside the main request-response cycle.
Security and audit
I implemented roles and permissions, JWT auth, change history, audit log and mechanisms supporting controlled access to data.
DESIGN
System architecture
The architecture was designed around three user panels: customer, staff and administrator. The Next.js frontend communicates with the Django/DRF backend, while background tasks are handled by Celery with Redis.
01
Users
Three user types with separate needs, permissions and workflows.
Client PanelStaff PanelAdmin Panel
02
Frontend
System interface, panel views, application state and API communication.
Next.js 14React QueryZustandTypeScript
03
Backend
REST API, domain logic, authentication and request handling.
Django 5.1DRFGunicornJWT
04
Domain Modules
Modules responsible for the main areas of the repair process.
RepairsClientsInventoryAnalyticsAuth
05
Data & Async
Database, cache, task queue and background operations.
PostgreSQL 16Redis 7CeleryCelery Beat
06
Security & Deploy
Access control, change history, reverse proxy and secure deployment.
RBACAudit LogNginxHTTPSCertbot
Why this architecture?
Three separate user flows
Customers, staff and administrators see the same repair process from different perspectives and have different needs.
Modular Django backend
Repairs, customers, inventory, analytics and auth are separated into modules with clear responsibilities.
Celery for background jobs
Notifications, reminders, backups and reports do not block the main request-response cycle.
RBAC and audit log
The system requires access control, change history and the ability to reconstruct the full repair workflow.
FEATURES
Key technical features
Staff Kanban Board
Drag-and-drop repair status changes. Columns: Accepted → In progress → Ready → Picked up. View of priorities, assignments and tickets requiring action.
Automatic notifications
Celery Beat triggers tasks related to status changes, reminders and customer communication. Customers can track repair progress without calling the service.
RBAC + Audit Log
Roles: customer, staff member and administrator. The system records status changes, ticket edits and user actions, making control and audit easier.
Inventory management
Spare parts catalog, reserving parts for repairs, stock levels, supplier orders and low-stock notifications.
Analytics and reports
The admin dashboard shows repair times, staff workload, revenue, most common issues and data needed for operational decisions.
Security and deployment
HTTPS with Let’s Encrypt, CSRF/XSS protection, rate limiting, data validation, role-based authorization and Django password hashing.
DEMO
System in practice
Key staff and admin panel views showing the real repair workflow: ticket handling, Kanban, repair details, change history, dashboard and service process management.
For confidentiality reasons, I do not provide public login access to the staff and administrator panels. Instead, I prepared anonymized system views that show the most important workflow elements: ticket handling, staff Kanban, repair details, change history, admin dashboard and service process management.
During a technical interview, I can walk through the system architecture, code and selected panel views via presentation or screen share.
Repair request form
A five-step form collects contact details, device information, delivery method and repair request summary.
Staff analytics
The KPI view presents revenue, completed repairs, work in progress, overdue tickets and status distribution.
My repairs
The repair table allows quick filtering of assigned tickets, statuses, customers, devices and actions requiring attention.
Staff dashboard
The operational panel combines active repair counters, next actions, work time and quick access to ticket handling.
Admin dashboard
The management view shows status pipeline, technician workload, monthly revenue and process alerts.
I prepared a full gallery of over 30 staff and admin panel views — from repair intake to dashboards, change history and service management.
View full gallery →CHALLENGES
Hardest problems
Areas where the project required the most architectural decisions.
01
Modeling the repair lifecycle
A repair ticket goes through many states, and each status can trigger different actions: notifications, reminders, customer visibility changes or staff queue updates.
Enum-based status field, explicit transition rules and Celery tasks triggered on status changes.
02
RBAC with three different UX flows
Customers, staff members and administrators have different needs, permissions and views of the same resource. The same repair object must be represented differently depending on the user role.
Custom DRF permission classes, separate serializers and controlled data representation for each role.
03
Implementation without a ready-made pattern
This was my first large project with the full Django + Next.js + Docker stack, so many architectural decisions had to be made independently.
Modular architecture, moving logic into services/selectors/serializers and regular code review with AI as support.
LEARNINGS
What I learned
How to translate real business processes into a data model and status lifecycle
Modular Django architecture — each app has a clear responsibility
Clean Architecture in practice: selectors, services and serializers
Docker + Nginx + Certbot — full web application deployment process
Managing complex RBAC permissions in DRF
Building from the user’s perspective — service experience gave me real context
DEMO
What you can check in the demo
repair request as a customer
repair status panel
staff Kanban board
status and assignment changes
administrator panel
change history and audit log
API documentation in the repo / code
Interested in this project?
I would be happy to talk more about the architecture, service process and technical decisions I made while building it.