Regulated Engineering Platform
An engagement spanning 16+ months connects 17 TypeScript workspaces, data operations, five workloads, and three deployment stages.
View the engineering platformSoftware Takeover
Take over existing software safely and make delivery reliable again.
The current technical owner or supplier is leaving, while your product must keep running. I take over the codebase, delivery, and operations under control and make the next changes predictable again.
The takeover starts with real access and a verified path into production. I document gaps, prioritise risks, and implement the critical changes myself.
When a takeover is needed
The software keeps running while ownership falls away.
A controlled takeover protects the live operation and restores a reliable route for changes.
- A supplier or responsible engineer leaves with an incomplete handover.
- Knowledge about architecture, data, or deployment sits with individual people.
- Builds and releases work, but the team cannot reproduce or explain them reliably.
- A backlog exists, but nobody can own a change safely through production.
Ownership
The takeover is proven through a real production path.
Documents provide orientation. The decisive test is whether the software can be built, tested, delivered, and observed.
- Inventory repositories, access, environments, and technical contacts
- Run the application locally and in a controlled environment
- Assess data flows, integrations, security boundaries, and operational risks
- Take one prioritised change through test, deployment, and production
- Record ownership, documentation, and the next development scope
Evidence
Ownership in established systems.
Both cases required learning an existing application, implementing changes directly, and controlling the production path.
E-commerce Cloud Migration
An established Magento platform with 40 storefronts moved through a rehearsed cutover into a controlled GCP and GKE environment.
View the cloud migrationTakeover
Secure access, prove the delivery path, resume development.
The sequence reduces the risk of damaging the product with a well-intended first change.
Establish access
Code, systems, providers, data paths, and existing documentation become available.
Reproduce the system
I build, test, and deploy the application and compare its real behaviour with the documentation.
Stabilise the risks
Blockers to operation and change are prioritised and fixed along a real delivery path.
Organise continued work
The team receives clear responsibilities, a prioritised scope, and a verified handover state.
Questions
Common points to settle before a takeover.
Which access is needed at the start?
At minimum: source code, the build and deployment path, runtime environments, monitoring, and contacts for product and operations. Missing access remains visible as a takeover risk.
Does the previous supplier need to be available?
A direct handover helps, but it is not required. Without the previous owner, analysis takes longer because architecture and operational knowledge must be reconstructed from code, configuration, and production signals.
Will you take over an unfamiliar technology stack?
That depends on the system and its risks. My focus is TypeScript products, APIs, PostgreSQL, cloud runtime, Kubernetes, and OpenShift. I assess other stacks before making a commitment.
How large should a software takeover be?
Defined projects start at €15,000. Ongoing development engagements start at €8,000 per month.
Software Takeover
Which responsibility must change hands before the next release can go live safely?
Describe the system, previous owner, known gaps, and time pressure. I will tell you how to define a workable takeover boundary.