Owned project area
I take ownership of a product, platform, or migration area through an agreed result.
Services
Product engineering for software that works in production.
I take responsibility for a defined technical area and work on the decisive parts myself: product code, integrations, cloud runtime, delivery, and monitoring.
Product engineering is my primary focus. Platform engineering supports it when delivery, migration, or operations determine whether the product succeeds.
Common starting points
Most engagements begin with one of these situations.
Build and modernise products
Product Engineering
I build new digital products and modernise established systems. I remain responsible for product decisions, frontend, backend, and production operations.
Common situations
- A new product needs technical ownership through production.
- An established product is difficult to extend or constrained by accumulated architecture.
- Important integrations, data flows, or operational concerns sit between several teams.
What I own
- Product and technical discovery with an implementable outcome
- Frontend, backend, APIs, authentication, and data models
- Integration with existing services and third-party systems
- Production readiness, automated delivery, and observability
- Documentation and handover to the future maintainers
Outcome
You receive a shipped product and a technical path your team can understand, operate, and extend.
Common technical context includes TypeScript, React, Next.js, Angular, Node.js, PostgreSQL, and AI features tied to a defined product need.
Cloud, delivery, and operations
Platform Engineering in application context
I take on platform work when it helps specific applications and teams. I build delivery and operations so developers and operators can understand and maintain them.
Common situations
- A Kubernetes, OpenShift, or cloud environment is blocking releases or migrations.
- Ownership between applications and infrastructure is unclear.
- A critical phase needs temporary senior platform ownership.
- GitOps, IAM, monitoring, or CI/CD exist but do not form a dependable delivery system.
What I own
- Target architecture and staged migration path
- Kubernetes, OpenShift, and cloud runtime in application context
- IAM, networking, security contexts, and policy
- Infrastructure as code, GitOps, and CI/CD
- Monitoring, alerting, and operational handover
Outcome
Your teams can trace a change from source control to the running system. Developers and operators can understand the platform decisions behind it.
Common technical context includes Kubernetes, OpenShift, Terraform, Ansible, Argo CD, GitLab CI, Prometheus, and Grafana.
Technical decisions remain tied to delivery.
If the technical goal, risks, or ownership boundaries are unclear, the first project phase focuses on analysis. I examine the existing system, document decisions, and test critical assumptions in code or infrastructure.
For migrations, this produces a staged path across applications, data, delivery, and operations. Cutover preparation, production signals, and handover are included in that path.
Technical direction
- Map existing system boundaries and constraints
- Make risks and unresolved decisions visible
- Define the technical outcome and delivery priorities
- Validate critical assumptions through implementation
Migration and cutover
- Connect the current system to the target platform
- Split the change into testable stages
- Protect ongoing operations during the migration
- Transfer knowledge and ownership to maintainers
Engagement
A defined responsibility with a clear outcome.
Scope, expected outcome, and handover are agreed at the start. The setup depends on the project and the existing team.
Embedded in your team
I work directly with engineering, product, and operations while owning and implementing a defined technical area.
Ongoing mandate
I stay involved across several phases when a product or platform needs continued senior ownership and implementation.
- Projects from €15,000
- Ongoing mandates from €8,000 per month
- DACH and EU, primarily remote
- On-site work by agreement
A strong fit
The engagement works best when someone with budget or delivery responsibility is involved and the project requires senior technical judgement with hands-on implementation.
- A defined product, modernisation, or migration objective
- An existing team or named internal owners
- Willingness to clarify technical and organisational boundaries
- A need for implementable ownership rather than a strategy presentation
Another setup will be more suitable when
- the requirement is extra capacity for an open ticket queue,
- no budget or responsible owner exists yet,
- the enquiry concerns recruitment, placement, or rate collection.
Frequently asked questions
Do you take on complete projects or join existing teams?
Both setups are possible. I can take responsibility for a defined part of the project or work within an existing team. Responsibility, outcome, and handover are agreed before the work starts.
Can a project begin with an architecture or system review?
Yes. The review becomes the first project phase. It produces documented decisions, a prioritised implementation plan, and practical validation of the most important assumptions.
Do you work alone?
You work directly with me. I integrate with existing teams and collaborate with internal or external specialists. I do not provide anonymous delivery teams or developer placement.
Do you require a specific technology stack?
No. The existing system and intended outcome determine the choice. My main areas are TypeScript products, APIs, cloud runtime, Kubernetes, OpenShift, GitOps, and observability.
Do you work remotely or on site?
Most work is remote across DACH and the EU. Workshops, kick-offs, and critical project phases can take place on site by agreement.
What budget should a project have?
Defined projects start at €15,000. Ongoing mandates start at €8,000 per month. The final scope follows an initial project assessment.
Project enquiry
Describe the current situation and desired outcome.
A short overview of the product, team, technical constraint, and intended start is enough for the first assessment.