Haydar Demir
How I work, what I enjoy building, and how I approach software.
I'm a software engineer, currently leading the Flutter team on a healthcare platform. Most of my work is mobile: architecture, hardware and platform integrations, and the delivery infrastructure that gets all of it into production reliably.
How I got here
I studied Computer Engineering at Kırıkkale University and graduated in 2019. My first professional years were agency work — web and mobile projects, short timelines, real users. That period taught me less about code quality than about how software behaves after it ships.
Since 2021 my focus has been Flutter. I started by building applications, then moved into defining the architecture and conventions teams build against. I've been working as a Flutter team lead since 2024, which splits my time between writing code, making technical decisions, and keeping the team's pace sustainable.
How I approach software
I treat architecture as a tool for legibility rather than an end in itself. The real test of a codebase isn't how elegant it is today — it's whether it can still be changed confidently after two years and three developers. So I try to keep layer boundaries obvious, dependency direction one-way, and conventions written down.
Hardware integrations have taught me the most. Working with Bluetooth devices, the happy path is maybe ten percent of the job; the rest is dropped connections, retries, timeouts and platform behaviour that differs in ways no documentation mentions. That's where the actual product lives.
I believe in automating anything that quietly produces errors when done by hand — release processes above all. It should not matter who cut the build.
What I'm interested in now
I'm trying to work out how far AI-assisted development actually goes in a real codebase — which classes of change I can delegate safely, and where reviewing the output costs more than writing it would have. Also mobile observability: what data from a phone needs to contain before it can genuinely diagnose a production problem.
I build small tools for myself, and I write. Writing is the fastest way I know to find out whether I actually understand something.