Öztemel
A software architecture practice in Amsterdam. Design, implementation, and review of distributed systems.
Good architecture is not about predicting everything. It is about making future change affordable.
Services
Architecture and design
Deciding how a system should be shaped before it is built: service boundaries, data flow, failure modes, and the non-functional requirements that determine whether a platform holds under load.
Implementation
Hands-on work alongside your engineers — services, event pipelines, APIs, and the infrastructure around them. The design and the code come from the same place.
Code and architecture review
Reading a codebase or a design and saying plainly what will break, what will slow the team down, and what to fix first. It takes a few days: reading the system, talking to the people who build and run it, and writing it up as an assessment your team can act on — current state, risks, and the options with their trade-offs. It covers architecture and common security practice; it is not a penetration test or a load-testing exercise.
Modernisation
Moving legacy platforms onto something maintainable without stopping the business running on top of them.
How we work
Most engagements move through four stages. Each one ends with something you can hold on to, and you decide whether to continue.
-
Discovery
Reading the system, the code, and how the team works around them. This ends with a written picture of where things stand and what is genuinely at risk — separated from what merely looks untidy.
-
Strategy and roadmap
Turning that assessment into a sequence: what to change, in what order, and what each step buys you. Weighed against the delivery commitments you already have.
-
Building
Implementing the plan alongside your engineers, adjusting it as the system tells us more. Working software at every step rather than a long silence before a large release.
-
Handover and support
Documentation, walkthroughs, and time set aside for your team to take full ownership. Continued support afterwards if you want it, but never as a dependency you are stuck with.
Experience
Twenty years of engineering, most of it on systems that carry money, messages, or traffic at scale — and much of it spent replacing such systems while they stayed in service.
-
Banking and payments
Reactive authorisation and payment services, API modernisation, and untangling microservices whose boundaries had blurred.
-
Telecommunications
Carrier-grade messaging platforms, geo-redundant deployments, and the security, auditing, and recovery layers beneath a billing product.
-
Insurance
Event-sourced policy lifecycle services and telemetry pipelines feeding pricing in real time.
-
E-commerce
Search, recommendation, and event processing for large product catalogues, and the platform behind AI-driven product discovery.
Tayfun Öztemel
Most of my work has been on the JVM, though I have gone outside it when a problem asked for it. Wherever it lands, what decides whether a system survives is rarely the technology — it is how quickly the team can change it and find out whether they were right. So I would rather ship something small and learn from it than get a large design right in private, and the systems I most enjoy are the old ones still carrying a business, where the cost of every shortcut taken along the way is finally legible. What I want at the end is something dependable, and simple enough that whoever comes next can follow it.