Solving complex problems with practical solutions.
Software engineer with a research background (PhD), combining engineering, research thinking, and founder instincts to move from confusion to execution.
- Break unclear problems into clear parts
- Design systems that fit real limits
- Iterate to improve
Focus
Startup / Founder Work
I’m building an AI-native business platform that automates internal operations and turns process intelligence into action. The goal is to reduce manual coordination, make workflows observable, and automate what should never have been a human bottleneck in the first place. I care about systems that hold up under real-world applications.
Research
I will have a PhD in Business Economics, focused on process mining pre-analysis. My work centers on what happens before you “run” process mining: how tasks, expertise, and data shape what you can reliably conclude. In practice, that means I’m opinionated about preprocessing, expert knowledge, and the organizational context behind it; because those decide whether insights are real or just noise.
Software Engineering
My engineering work is mostly backend and architecture, with a product mindset: ship something useful, then improve it relentlessly. I design systems for maintainability, clear boundaries, and long-term change. I hold bachelor’s and master’s degrees in software engineering, and increasingly work on ML/AI engineering when it directly improves the product and the workflows around it.
Process Intelligence
I treat process intelligence as a practical lens on how work actually happens—then I use it to drive automation and better decisions. The research side keeps me honest about assumptions; the builder side keeps me honest about usefulness.
I’m interested in building systems that work in the real world — and improving them over time.
Thinking
I approach problems by first making them concrete. When something is unclear, I focus on understanding how the system actually behaves—what happens, who is involved, and where decisions or handoffs break down. From there, I reduce the problem to the smallest version worth solving and build something that can be tested in the real world.
I prefer simple designs that can change over time. Rather than aiming for completeness upfront, I iterate based on evidence: measure what happens, automate what repeats, and adjust where outcomes diverge from intent. Progress, for me, is not theoretical correctness but whether a system becomes more reliable, usable, and easier to improve.
In practice, this means:
- Start small and iterate
- Prefer simple designs
- Design for change
- Automate repeatable work
- Measure outcomes and adapt
Contact
If you’d like to discuss ideas, collaboration, or future work, you can reach me here. I read everything and respond when there’s a clear reason to continue the conversation.