Behind the
systems.

Technology should make things work better.

As CTO & IT Development Manager at GladTeknik, a Danish repair and IT service company, I work on the software behind everyday operations. Much of my engineering work is on System3, the in-house platform linking repair cases, customer communication and the customer portal. I work across architecture, implementation and the needs of the people using it.

I start with how the work is done: what technicians need at the bench, what support needs in the inbox and what customers should be able to handle themselves. I favour a clear specification, explicit non-goals and small, testable changes over building everything at once.

My perspective comes from starting out repairing electronics, then working with purchasing and day-to-day operations before moving into IT and development leadership. Understanding the people and processes around a system is just as important to me as building the software itself.

I have seen how a seemingly minor software decision affects an entire chain of work. A technician may need the right device history, support needs a clear next action, finance needs reliable references, and the customer needs an understandable explanation. Good systems should account for those perspectives without making everyone learn the underlying technical complexity.

The work behind
the decisions.

I did not start by building software. I started by diagnosing devices, dealing with uncertain faults and explaining outcomes to customers. Purchasing and operations then showed me a different set of dependencies: a repair can be technically straightforward but still be delayed by a missing part, unclear ownership or incomplete information.

Today that experience shapes my work as CTO & IT Development Manager. When a support team asks for a new workflow, I try to understand the handover, permissions, exceptions and recovery path before deciding how to implement it. The best improvement is often the one that removes repeated manual coordination, not the one that adds the most features.

I also work directly with business and public-sector customers. Their feedback provides a useful test of whether a process that makes sense internally is equally understandable to someone outside the organization. The software is developed by a team; my contribution spans hands-on engineering, requirements and the operational context around each change.

A broader view
of building.

Curiosity doesn't
stop at work.

I study Software Engineering at the University of Southern Denmark (SDU). My bachelor project explores the design and implementation of an HRM module in System3, connecting academic methods with the realities of an existing software platform.

At home, I run a homelab for self-hosting, networking, virtualization, backups and automation. Operating systems myself is a useful reminder that the real work often begins after deployment.