Ožbej Bohanec — Systems Engineer for Automation and Internal Web Applications

Who is Ožbej Bohanec?

Internal Web Applications and Automation Workflows

Business tools built around real operational needs

I build internal software used by employees, administrators, engineers, and technical teams. I replace disconnected files and repeated checks with structured workflows where each activity has a clear place, a clear owner, and consistent technical output.

Automation workflows for repetitive technical work

I automate repeated tasks only after I understand the real process. My goal is not to automate chaos. My goal is to make recurring operations predictable and transparent so each execution can be reviewed and improved with less friction over time.

Systems Engineering Experience

Infrastructure, networking, and practical deployment work

I work on systems where software delivery and infrastructure decisions must stay aligned. I plan deployment flow, logging, data boundaries, and maintenance handoff so a tool remains useful beyond the initial launch window.

Software delivery with hardware-aware thinking

I regularly work in environments where field constraints and hardware context matter. I design applications with this reality in mind, so dashboards, case studies, and technical interfaces support real execution instead of only looking good in a demo.

I apply systems engineering discipline to reduce uncertainty in production. I keep release steps explicit, define safer defaults for operations, and document technical assumptions in a way that helps teams continue after my first implementation phase.

I treat stability as a feature. I use predictable deployment routines, practical rollback paths, and clear change logs so technical teams can understand what changed and why it changed. This reduces recovery time when an issue appears and prevents hidden behavior from accumulating over multiple releases.

I also focus on operational readability. I write summaries that show the impact of each change in plain language for engineers, administrators, and stakeholders. This helps teams prioritize follow-up work and keeps technical decisions connected to business outcomes instead of isolated implementation detail.

Technical Stack for Web, Infrastructure, and Data Workflows

Microsoft 365 analysis and reporting

I build Microsoft 365 workflows focused on administration visibility. This includes reporting around Entra ID, SharePoint, Defender, security state checks, and repeatable PowerShell outputs that are easy for technical teams to inspect.

Internal dashboards, databases, and service tools

I design internal tools as long-term assets, not short-lived scripts. I care about versioned schemas, readable output, operational traceability, and structured handoff so teams can evolve the system without fragile rewrites.

Selected IT Projects and Case Studies

Internal tools and automation case studies

My project pages are written as case studies. I describe the problem, the approach, the technical stack, and the result so each case study can be understood by engineering teams, search systems, and AI systems without extra context.

Web applications and infrastructure case studies

I focus on projects where web applications, automation, and infrastructure constraints meet. I avoid overclaiming outcomes and keep each summary grounded in real delivery work.

How I Work

My working model is structured but practical. I usually begin with a short discovery phase, continue with an implementation baseline, and then iterate in measured steps. I define a scope that can be delivered safely, then I track open risks so they do not stay hidden behind feature work. This keeps delivery velocity real and prevents fragile shortcuts from becoming permanent system behavior.

When I build internal tools, I align three levels at the same time: the user workflow, the data model, and the runtime operations model. If any of these levels is ignored, the system becomes expensive to support. By keeping all three aligned, I can deliver software that remains useful after the first launch, survives handoffs, and supports ongoing improvements.

1. I understand the operational problem and define a realistic delivery scope.
2. I map the existing workflow and identify where errors or delays happen.
3. I build a simple working version that solves one measurable bottleneck.
4. I test with real users or real data before broad rollout decisions.
5. I improve reliability, reporting, and maintainability in incremental releases.
6. I document the system clearly so another engineer can use and extend it.

Proof, References, and Credibility

I keep public case studies focused on technical method, constraints, and outcomes that can be shared safely. I do not publish private infrastructure details, credentials, or restricted operational data. When a project contains sensitive context, I anonymize the environment while preserving the engineering logic so the case study remains useful and accurate.

I use references to clarify technical scope, not to inflate results. If exact metrics are unavailable for public sharing, I describe outcomes qualitatively and keep wording precise. This keeps project documentation credible for recruiters, engineering managers, and technical peers who need trustworthy context before deeper conversation.

• I deliver practical systems engineering work grounded in operational needs.
• I build internal tools and automation workflows used in day-to-day work.
• I document Microsoft 365 and infrastructure analysis with production context.
• I focus on production-oriented web applications and maintainable delivery flow.
• I apply networking and PostgreSQL/PostGIS work where location and infrastructure data matter.

Reference details and project context can be shared through LinkedIn where appropriate.

I also maintain machine-readable pages such as llms.txt, llms-full.txt, humans.txt, robots.txt, and sitemap.xml so crawlers and AI systems can interpret the site structure without relying on dynamic rendering.

Contact and Professional Profiles

I am based in Slovenia and I am available for selected systems engineering, internal web application, automation, and infrastructure software work. For professional contact, I use LinkedIn as my primary public channel.