In a no-obligation conversation, we'll figure out together how we can best support you. Concrete next steps, no sales pitch.
Backend services, APIs and platform components built for Azure. Cloud-native patterns, clean identity model, observability from day one.
Refactor: extract pricing rules into aggregate
8 files changed · +312 −187
Trusted by engineering teams at
If any of these resonate, a conversation is worth your time.
Manual approvals, fragile pipelines and cross-team dependencies slow every delivery. Features are done but never reach production.
What was designed two years ago as a clean service cut no longer matches product reality. Workarounds grow, technical debt grows with them.
Tests exist but don't cover what actually breaks. Bugs are caught in production, not in the pipeline.
10×
Faster deployments
From quarterly release trains to multiple daily deployments through CI/CD hardening and trunk-based development.
<1%
Error rate during refactor
Strangler-fig pattern and characterization tests keep the system running while we rebuild it.
70%
Less onboarding time
Clean architecture documentation and consistent code conventions significantly reduce time-to-first-commit for new engineers.
Every phase has a clear output and a measurable transition. Not a waterfall, iterative refinement.
Stakeholder mapping, target picture, success criteria and scope. We understand your business before we write code.
Your time
8-16 h
Our work
1-2 weeks
From user interviews, system observation and task analysis we produce verifiable requirements and first prototypes.
Your time
4-8 h per week
Our work
2-4 weeks
Bounded contexts, interfaces, data models and architecture decisions captured in ADRs.
Your time
2-4 h per week
Our work
2-3 weeks
Trunk-based development, pair programming on critical sections, automated tests at every level.
Your time
sprint reviews
Our work
ongoing
Blue-green deployments, feature flags, observability. We hand you a system, not just artefacts.
Your time
demo + acceptance
Our work
per sprint
SLOs, alerting, postmortem culture. We stay accountable until your team safely owns operations.
Your time
handover workshops
Our work
as needed
Stakeholder mapping, target picture, success criteria and scope. We understand your business before we write code.
Your time
8-16 h
Our work
1-2 weeks
From user interviews, system observation and task analysis we produce verifiable requirements and first prototypes.
Your time
4-8 h per week
Our work
2-4 weeks
Bounded contexts, interfaces, data models and architecture decisions captured in ADRs.
Your time
2-4 h per week
Our work
2-3 weeks
Trunk-based development, pair programming on critical sections, automated tests at every level.
Your time
sprint reviews
Our work
ongoing
Blue-green deployments, feature flags, observability. We hand you a system, not just artefacts.
Your time
demo + acceptance
Our work
per sprint
SLOs, alerting, postmortem culture. We stay accountable until your team safely owns operations.
Your time
handover workshops
Our work
as needed
Stakeholder mapping, target picture, success criteria and scope. We understand your business before we write code.
Your time
8-16 h
Our work
1-2 weeks
From user interviews, system observation and task analysis we produce verifiable requirements and first prototypes.
Your time
4-8 h per week
Our work
2-4 weeks
Bounded contexts, interfaces, data models and architecture decisions captured in ADRs.
Your time
2-4 h per week
Our work
2-3 weeks
Trunk-based development, pair programming on critical sections, automated tests at every level.
Your time
sprint reviews
Our work
ongoing
Blue-green deployments, feature flags, observability. We hand you a system, not just artefacts.
Your time
demo + acceptance
Our work
per sprint
SLOs, alerting, postmortem culture. We stay accountable until your team safely owns operations.
Your time
handover workshops
Our work
as needed
What we deliver in the discovery phase: feasibility study, requirements spec, early prototypes.
Based on the current needs and requirements of your organization, a feasibility study is conducted to evaluate the technical and economic feasibility of the project. This involves evaluating the use of current software and hardware technologies and assessing the project initiative from a business standpoint based on the results and budget constraints.
From observing your existing system and application landscape, discussions with potential users, and task analyses, initial system requirements are developed. These can be used for implementing initial prototypes and evaluating system models.
To have a clear overview of the planned functionality and specific requirements to be met, architecture diagrams, a specification sheet, and specific steps during the project initiative are documented.
In order to validate the identified functional and technical requirements, initial prototypes are possible before a concrete project start. This gives you a first impression of the technical capabilities of your final solution.
Sample topology for a customer-facing web application with clear layering and cloud-native building blocks.
Front Door / CDN
Edge routing
API Management
Gateway
Application Gateway
WAF + SSL
App Service
Web + API
AKS
Kubernetes
Container Apps
Workers
Functions
Serverless
Service Bus
Async messaging
Event Hubs
Event streaming
Event Grid
Pub/Sub
Logic Apps
Orchestration
PostgreSQL
Transactional
Cosmos DB
Document
Blob Storage
Files
Application Insights
APM
Log Analytics
Logs & queries
Key Vault
Secrets
Four aspects we look at in every architecture review. Microservices vs. modular monolith is just one of them.
Microservices, mono- or modular monoliths, serverless, or container orchestration? The selection of software architecture depends on the requirements for scalability, performance, and maintainability of your application. I am happy to assist you in selecting the appropriate software architecture for your project.
Every software solution is embedded in an existing ecosystem of surrounding systems that are interconnected through interfaces and communication channels. Analyzing the surrounding systems helps to identify the requirements for the software architecture and define the interactions between the surrounding systems.
Who communicates with whom and how? Defining the communication channels between subsystems and surrounding systems is an important step in specifying the requirements for the software architecture and modeling the interactions between the subsystems and employing suitable technologies.
The software architecture should be designed to allow for future expansions and adjustments. By using microservices, modular monoliths, or serverless architectures, you can make your software solution flexible and scalable.
We choose technologies by requirement, not by fashion. These are the tools we use most often in enterprise contexts.
Frontend
Web interfaces still maintainable two years from now.
Backend
Stable services, built for load and compliance.
Data
Persistence, streaming and analytics, fitted to the domain.
Infrastructure
Reproducible environments, declarative and auditable.
Consistent conventions, small pull requests, tests that verify real behavior. A use case from a bounded context — the application service invokes the aggregate, business rules and domain events live there.
1@ApplicationScoped2public class PlaceOrder {34 @Inject Customers customers;5 @Inject Orders orders;6 @Inject Clock clock;78 @Transactional9 public OrderId handle(PlaceOrderCmd cmd) {10 var customer = customers.byId(cmd.customerId())11 .orElseThrow(() -> new CustomerNotFound(cmd.customerId()));1213 var order = customer.placeOrder(cmd.cart(), clock.now());14 orders.add(order);1516 return order.id();17 }18}Three practice areas we documented from real projects. No generic buzzwords, decisions with evidence in the blog.
GitLab Runner in your Azure subscription instead of shared cloud runners: no egress, full control over cache, secrets and network visibility.
Which compute platform fits which workload? We avoid the mistake of putting everything on AKS when an App Service or Container App is enough.
Application Insights for telemetry, Data Collection Rules for structured custom logs. SLOs as code, alerts versioned with the app.
How we ensure consistent quality, at code, process and stakeholder level.
Every development team has its own methods for project organization, acceptance of partial results, and internal guidelines for implementing ideal solutions. As part of development teams in organizations oriented towards SAFe and Scrum, I am able to take on stakeholder communication aside from developing software solutions through Iteration Reviews, Art-Syncs, and other stakeholder communication.
By using versatile measures such as code reviews, high test coverage, and an iterative approach, your feedback can actively be considered in the technical solution throughout the development process.
Trivy in the pipeline scans images for CVEs and misconfigurations before they reach the registry. Results as a quality gate, not as an email.
Documented from our engineering practice: compute choices, CI/CD self-hosting, container security and application observability.
In this blog post, you'll get a detailed overview of Azure Container Apps, its use cases, and special features. Additionally, the key differences to other container solutions in Azure are highlighted, enabling you to make an informed decision for your cloud architecture.
Read article
This article shows how to securely and reliably run GitLab Runner in Azure and compares Azure Container Apps, App Service, and virtual machines as hosting options.
Read article
A hands-on guide on how to automatically scan container images, registries, and Kubernetes clusters for vulnerabilities using Trivy and how to fix security issues early.
Read article
A hands-on overview of how to use Data Collection Rules and Data Collection Endpoints in Azure to efficiently collect custom logs.
Read article
Azure App Registrations and Enterprise Applications can be hard to distinguish. In this article I explain the details and dependencies of each Resource Type.
Read article
Many Terraform projects start lean and end up as monoliths. This guide explains how to migrate Azure infrastructure to modular states, clear module boundaries, and resilient CI/CD governance without downtime.
Read article
Mertkan Henden
Cloud engineering consultant · Heilbronn
I don't believe in consultants who review code without writing any themselves. In my projects I commit, open pull requests and sit in pair programming. That's the only way to advise on engineering honestly, by actually doing it.
— Mertkan Henden