I keep my active engineering portfolio with short context, constraints, solution choices, and verifiable outcomes for each project.
me-page
Short description: A multi-page portfolio website built to present my engineering profile, project case studies, and machine-readable technical context.
Role: I was responsible for frontend structure, SEO, AI-readable context files, Docker packaging, and deployment workflow design.
Context: The problem was fragmented technical presentation across informal channels. Existing process was manual and not production-ready.
Constraints:
- Static-site architecture with minimal runtime complexity.
- Deployment had to stay compatible with GitLab CI and Portainer Git stack updates.
- Credentials and infrastructure secrets had to stay outside version control.
Solution: I built a static site with clear project pages, structured metadata, AI-readable context files, and a containerized Nginx delivery path.
Key technical decisions:
- Used static HTML/CSS/JS because reliability and long-term maintainability were the primary requirements.
- Designed Docker + GitLab CI + Portainer GitOps flow to handle repeatable deployment and rollback safety.
- Avoided direct SSH deploy because it increases operational drift and secret-handling risk.
Result: I delivered a production-ready portfolio with stable publishing workflow and machine-readable discovery support.
References:
- Metrics: Multi-page site with dedicated project, stack, experience, and AI context resources.
What I learned: This project improved my understanding of SEO-aligned static delivery and disciplined deployment process design.
bohanec-admin-energijarr-django
Short description: A Django operations platform built to manage energy, location, sensor, tariff, and analytics data for technical operations.
Role: I was responsible for backend workflows, operational data model maintenance, Docker-based setup, and engineering support.
Context: The problem was operational data spread across inconsistent workflows. Existing process was slow and error-prone.
Constraints:
- Legacy compatibility requirements around Django 3.1.6 and existing schema behavior.
- MySQL data integrity and migration safety had to be preserved.
- Operational users needed continuity while improvements were delivered incrementally.
Solution: I built and maintained a Django application with structured admin surfaces, REST API paths, and reproducible local/container startup flow.
Key technical decisions:
- Used Django because the project needed rapid admin productivity and mature ORM workflows.
- Designed Docker Compose flow to handle consistent run/migrate/static collection steps.
- Avoided disruptive rewrites because they would increase risk for existing operational users.
Result: I delivered a more stable and maintainable base for daily operational data administration.
References:
- Metrics: Platform covers locations, sublocations, sensors, data sources, tariffs, analytics, and API integration paths.
What I learned: This project improved my understanding of maintaining legacy-critical Django systems without breaking operational continuity.
proxmox-mcp-ai
Short description: A Proxmox-oriented integration repository built to establish a safe baseline for MCP/AI-assisted infrastructure workflows.
Role: I was responsible for repository setup, integration direction, and security-first planning for Proxmox automation use cases.
Context: The problem was missing standardized workflow for AI-assisted Proxmox operations. Existing process was manual and fragmented.
Constraints:
- Repository started as a greenfield initialization with no implementation history.
- Infrastructure credentials must stay out of git and out of static config files.
- Automation design had to prioritize safety over speed.
Solution: I created the project baseline and defined a secure direction for integrating Proxmox operations through controlled interfaces.
Key technical decisions:
- Used incremental repository bootstrapping because infrastructure automation must start from explicit trust boundaries.
- Designed the flow to handle token-based and externalized credential management.
- Avoided direct hardcoded host credentials because that creates immediate security risk.
Result: I delivered a clean starting point for future Proxmox integration and governance.
References:
- Metrics: Repository initialized and ready for controlled implementation phases.
What I learned: This project improved my understanding of secure-by-default planning for infrastructure automation systems.
rcum-optika-zemljevid
Short description: A Web GIS system built to manage optical cable infrastructure geometry, metadata, and editing workflows on a map.
Role: I was responsible for full-stack architecture across Next.js frontend, Python backend, and PostgreSQL/PostGIS data layer.
Context: The problem was fragmented cable and node planning data. Existing process was manual and difficult to validate spatially.
Constraints:
- Geospatial precision and schema consistency had to be reliable for operational data.
- Authentication and session handling had to work with browser-based workflows.
- Map editing UX had to support complex domain entities without losing performance.
Solution: I built a Next.js map workspace with a Python backend and a PostGIS model layer including migrations, seed data, and geometry controls.
Key technical decisions:
- Used PostgreSQL + PostGIS because spatial indexing and geometry types were mandatory.
- Designed SQLAlchemy/Alembic-backed schema flow to handle long-term evolution and auditability.
- Avoided flat-file geometry management because it would increase drift and reduce integrity.
Result: I delivered a maintainable GIS foundation with practical cable/node editing workflows and better planning control.
References:
- Metrics: Spatial schema includes LINESTRING, POINT, and POLYGON entities with GIST indexing and migration workflow.
What I learned: This project improved my understanding of balancing rich GIS UX with strict geospatial data integrity.
Dashboard_FrontEnd
Short description: A Next.js dashboard frontend built to provide modular operational views for projects, schedules, analytics, and administration.
TS
Role: I was responsible for frontend architecture, UI composition strategy, and integration-ready client workflows.
Context: The problem was a need for one structured interface across multiple operational modules. Existing process was fragmented between tools.
Constraints:
- Frontend had to support many modules while staying maintainable.
- Type safety and UI consistency were required across reusable components.
- Deployment needed to remain container-friendly and CI-compatible.
Solution: I built a Next.js + TypeScript frontend with modular routes, reusable UI components, and charts/forms suitable for operational workflows.
Key technical decisions:
- Used Next.js App Router because route-driven module composition was a core requirement.
- Designed typed form/validation flow with React Hook Form and Zod to handle safer input management.
- Avoided ad hoc page-specific state patterns because they increase maintenance cost at scale.
Result: I delivered a coherent dashboard surface ready for integration with backend APIs and production builds.
References:
- Metrics: Multi-section route architecture includes admin, projects, settings, statistics, and scheduling views.
What I learned: This project improved my understanding of scaling frontend architecture across many operational modules.
Dashboard_BackEnd
Short description: A FastAPI backend built to provide secure APIs for project tracking, time, mileage, schedules, and task workflows.
Role: I was responsible for backend architecture, data modeling, migration flow, and authentication design.
Context: The problem was fragmented operational records without one reliable API layer. Existing process was manual and inconsistent.
Constraints:
- Authentication had to support secure sessions and OAuth providers.
- Schema evolution had to be explicit and migration-safe.
- API behavior had to remain stable for frontend integration.
Solution: I built a FastAPI service with SQLAlchemy models, Alembic migrations, Pydantic validation, and session/auth security flows.
Key technical decisions:
- Used FastAPI because typed API contracts and development velocity were both important.
- Designed SQLAlchemy + Alembic architecture to handle schema lifecycle control.
- Avoided schema changes without migrations because that introduces deployment and data risk.
Result: I delivered a backend foundation that supports multiple operational domains through one coherent API service.
References:
- Metrics: Covers project management, time tracking, mileage logging, scheduling, and task/idea endpoints.
What I learned: This project improved my understanding of secure API lifecycle management in production-oriented FastAPI systems.
money_manager (SpendLens)
Short description: A personal finance and receipt-processing web app built to manage spending with OCR-assisted data extraction and reporting.
Role: I was responsible for full-stack implementation, authentication, data storage strategy, OCR integration, and deployment setup.
Context: The problem was manual expense tracking with weak traceability. Existing process was slow and inconsistent.
Constraints:
- Receipt uploads had to be stored safely with per-user separation.
- Authentication had to stay secure while preserving usability.
- Public access needed reverse-tunnel exposure without direct host exposure.
Solution: I built a Next.js + PostgreSQL system with Auth.js credential flow, OCR provider integration, Docker deployment, and Cloudflare Tunnel routing.
Key technical decisions:
- Used Next.js full-stack approach because API routes and UI cohesion simplified deployment and maintenance.
- Designed plain PostgreSQL schema flow to handle deterministic initialization and migrations.
- Avoided committing OCR credentials because secret leakage would create severe security exposure.
Result: I delivered a practical finance workflow with faster receipt processing and structured expense records.
References:
- Metrics: Includes auth, receipts, OCR adapters, Docker Compose deployment, and Cloudflare tunnel-based exposure.
What I learned: This project improved my understanding of secure document-processing workflows and production web app deployment patterns.
CnsViz
Short description: A backend-first CNS platform built to design cabinet projects in an editor API and serve read-only runtime data safely.
C#
.NET
Role: I was responsible for backend architecture, package integrity flow, storage design, and runtime service boundaries.
Context: The problem was the need for controlled project editing with signed runtime delivery. Existing process was fragmented and harder to verify.
Constraints:
- Runtime consumption had to be read-only and verifiable.
- Package export required signing and integrity checks.
- Telemetry ingest had to support real-time operational visibility.
Solution: I built a .NET architecture with Core, Storage, Editor API, and Runtime API modules, plus signed package export/verification and telemetry paths.
Key technical decisions:
- Used separated Editor and Runtime APIs because write/read isolation reduces operational risk.
- Designed signed package workflow to handle artifact integrity before runtime serving.
- Avoided mutable runtime endpoints because they would break trust boundaries.
Result: I delivered a secure backend foundation for CNS project lifecycle and runtime status distribution.
References:
- Metrics: Implements dual API services, signed package export/verification, telemetry ingest, and SignalR status hub.
What I learned: This project improved my understanding of boundary-driven backend architecture for critical runtime systems.
CNS_Ridizajn_FrontEnd
Short description: A Next.js frontend application built to support CNS and HVAC visualization workflows with 2D and 3D interactive surfaces.
Role: I was responsible for frontend interaction design, module structure, UI state flows, and operational screen behavior.
Context: The problem was fragmented operator views across alarms, service, and equipment context. Existing process was slower for monitoring and response.
Constraints:
- UI had to support many operational views while keeping navigation predictable.
- State management needed to stay consistent across CNS, HVAC, and room-design modules.
- 3D/visual components had to coexist with practical control-room workflows.
Solution: I built a Next.js frontend with dedicated module routes, Zustand stores, reusable UI components, and mixed 2D/3D visualization workflows.
Key technical decisions:
- Used TypeScript-based component architecture because operational UIs need reliable contract discipline.
- Designed store-based state management to handle multi-screen synchronized behavior.
- Avoided monolithic single-page logic because it would reduce maintainability and testability.
Result: I delivered a richer operational frontend base for CNS/HVAC workflows and iterative feature delivery.
References:
- Metrics: Includes dashboard, alarms, floor-plan, history, service, schedules, and room-design modules.
What I learned: This project improved my understanding of complex operational frontend composition with mixed visualization modes.
