Code, decisions, and things learned.
Building systems that remain dependable as they evolve.
I’m a software architect based in Ankara, focused on backend systems and technical leadership. I shape system architecture, own technical decisions, and guide engineering direction across teams while staying involved in implementation.
My work brings together data integrity, service coordination, infrastructure modernization, and operational visibility. I’m interested in how these concerns interact, especially when a change crosses the boundaries of a single component.
I establish shared engineering standards and follow architectural decisions through implementation and operation. My focus is on their long-term impact: systems that remain dependable, maintainable, and able to evolve.
Leading engineering across connected systems, combining architectural decisions with hands-on development. I coordinate changes across teams, establish shared contracts and engineering standards, and guide delivery with a focus on compatibility, operational visibility, and reliability.
Led a cross-functional engineering team while owning architectural design and implementation. I improved delivery processes, mentored engineers through individual development plans and technical training, and stayed involved in code reviews and critical implementation work.
My earlier roles include Software Engineering Team Lead and Senior Software Engineer at Algoritma, Senior Software Developer at Edenred Türkiye, and Chief Technology Officer at Yüce Yazılım ve Danışmanlık.
Before that, I worked across full-stack and web development roles and founded BITSTORM Software. This background brings together hands-on engineering, technical leadership, and the experience of building a business.
Maintaining consistent outcomes across connected services. My work addresses concurrent operations, repeated requests, and the boundaries between a completed operation and the systems that reflect its state.
I work on making repeated and concurrent operations behave predictably, with clear ownership of state and explicit completion rules.
That includes separating essential state changes from supporting operations, accounting for partial failures, and verifying that recovery preserves the intended outcome.
Keeping connected components aligned as their state changes independently. My contributions focus on communication contracts, lifecycle management, and predictable recovery when connections or operations are interrupted.
I treat transitions, interruptions, and recovery as part of the system’s normal behavior. Each component needs a clear understanding of the state it owns and the information it exchanges.
My work includes aligning contracts between components, defining lifecycle boundaries, and keeping external behavior consistent while retaining useful diagnostic context.
Evolving shared backend components while preserving existing application behavior. My work includes managing dependencies, making integration boundaries explicit, and using regression testing to validate changes across services.
I approach infrastructure changes by first establishing the behavior that must remain stable. This provides a clear comparison point as shared components and their dependencies evolve.
Verification covers the affected boundaries and consumers, so a change is assessed by how the system behaves as well as whether the new implementation builds.
Making system behavior easier to understand during everyday operation and failure. I work on consistent diagnostic context, useful operational signals, and shared conventions that support investigation across services.
I focus on preserving the context needed to understand an operation across component boundaries, while keeping diagnostics consistent and sensitive information protected.
Useful visibility also requires restraint: distinguishing expected behavior from unexpected failures, reducing noise, and checking that operational signals retain their meaning as the system changes.
Work that is waiting and work that is actively consuming resources have different needs. Understanding that distinction helps make execution paths easier to reason about.
I consider how work is scheduled, where it waits, and how completion or failure moves through the system. A local implementation choice can affect the capacity and responsiveness of the whole application.
A new implementation is only one part of a change. The transition must also account for existing dependencies, ongoing operations, and components that may evolve at different times.
I look for a clear compatibility boundary, a way to verify behavior, and a recovery path. These considerations belong in the design of the change, alongside the desired final state.
A boundary is useful when its responsibilities remain clear across data access, communication, processing, and recovery. Defining it in one component is not enough.
I consider where context originates, which component owns it, and how it is preserved as work moves through the system. Explicit ownership makes both normal behavior and failure easier to understand.
Backend systems
Service boundaries & contracts
Data integrity
Concurrency & state coordination
Infrastructure modernization
Compatibility & verification
Observability
Diagnostics & recovery
Paste two JSON values to see what changed. Object key order is ignored; arrays are compared by position.
Ready to compare.
No uploads or storage. Up to 100 KB per input; the first 200 differences are shown.
Away from the keyboard, I’m a dad who also enjoys 3D modeling and 3D printing. I like taking an idea from a digital model to something I can hold in my hands.