Developer turned architect with a strong product and quality mindset, based in Berlin.
I started close to the code and still like being close enough to understand the technical details. Over time my work moved more into architecture, DevOps, product thinking, and the bridge between engineering, business needs, and the people who have to make a system work every day.
I care a lot about quality in the details. Sometimes probably a little too much for the comfort of everyone around me, but usually for a good reason: small unclear decisions become expensive later.
| Focus | Product-minded technology leadership, architecture, DevOps, and delivery systems |
| Strength | Connecting product needs, technical depth, and practical execution |
| Quality bias | Precise about details before they turn into incidents, rework, or slow teams |
| Current angle | Using AI and automation without losing engineering discipline |
- Solving the actual problem, not just shipping the visible feature.
- Keeping software understandable after the first version is done.
- Making technical trade-offs explicit enough that product, business, and engineering can move in the same direction.
- Using automation and architecture to remove friction, not to create a new layer of complexity.
- Product-minded technical leadership: connecting technical decisions with the outcome the product is supposed to create.
- Architecture with practical edges: enough structure to make systems maintainable, not so much that teams stop moving.
- DevOps & delivery experience: Azure, Azure DevOps, CI/CD, build agents, deployment workflows, and the details that decide whether delivery is smooth or painful.
- Quality pressure: a healthy, occasionally annoying attention to the details that later become incidents, rework, or slow-moving teams.
I am not limited to one vendor or one stack, even though a lot of my public writing has been around Microsoft Azure and Azure DevOps. The interesting part is rarely the logo on the service; it is whether the technology helps solve the problem with the right amount of reliability, cost, and maintainability.
I write about Azure, DevOps, automation, and things I had to figure out in practice on RazorSPoint.
- Scalable Container Based Azure Pipelines Pools with Azure Container Apps
- How to Preview and Test a Changing YAML Pipeline on Azure DevOps
- Variables Cross Stage in Azure DevOps with YAML
- What happens to my agent, when the PAT token on VSTS expires?
- Building products that solve the actual problem, not just the visible symptom.
- Using AI in product development without losing engineering discipline.
- Improving developer experience without hiding important technical details.
- Startup engineering decisions: what to build now, what to postpone, and what not to overcomplicate too early.
Community, speaking, and earlier public work
I have been part of the Berlin Azure community for years, including time as a co-organizer of Azure Meetup Berlin. I have also shared practical Azure and DevOps topics in meetups, smaller conferences, blog posts, and German developer magazines.
Those things are not the center of my work today, but they reflect something that still matters to me: explaining technology in a way that helps other people make better decisions.
- Developer, architect, and DevOps engineer in Berlin.
- Working with DB Systel GmbH.
- Author of RazorSPoint, my DevOps and cloud engineering blog.
- Humboldt-Universität zu Berlin alumnus.
- Certifications include Microsoft Certified: Azure Fundamentals and Agile Product Owner Role: Foundations.
- Website: razorspoint.com
- LinkedIn: linkedin.com/in/sebastianschuetze
- GitHub: github.com/SebastianSchuetze