Most engagements begin with one of the patterns below. The assessment framework is the same in each case — we name the situation only to frame the first conversation.
Rescue work is controlled, senior-led and intentionally narrow in scope. Before we begin, we make sure the situation is one we can actually move forward.
Two compact assessment steps before any larger commitment. Both produce written, hand-off-able output. You can stop after either step and use the recommendation with another team.
A controlled sequence, not a fixed package. Each step produces written output you own. Continuation is always your decision — never an automatic condition of the assessment.
A clear picture of what you actually hold and a controlled path to the rest. Where access is incomplete, we say so plainly.
An honest read on whether the system is recoverable, in writing, that you can share internally.
A hand-off-able recovery recommendation you can give to any technical team — ours or another.
A path from a stuck or broken system to a stable, owned setup — only if you decide to continue.
Scope depends on system state, the access situation, integrations and recovery requirements. We confirm the scope of each step in writing before it begins.
Each step has a defined deliverable. You can stop after any step without further commitment. Timing depends on the access situation and is never pre-promised before we have seen the system.
H-Studio Berlin is an engineering studio, not a body-shop. Rescue work especially needs senior judgement — the first assessment sets the framing for everything that follows, and that is not a job for a junior with a checklist.
Every rescue is led by senior engineering, from the first assessment through to the recovery decision. Behind that sits the rest of the engineering team — you are never routed into an account-manager chain.
Response targets depend on current capacity and begin only once the required access and NDA are in place. If we are at capacity, we say so on the first call rather than stretch.
Use the form or email to describe the situation — current status, what is stuck, who still holds access. It routes to the same inbox, and a mutual NDA is in place before we look at any code or system access. Do not send credentials, source code or sensitive production data through the enquiry form or messaging channels.
Two patterns that don't sit alongside the others above but are common enough to call out explicitly.
You bought a custom solution. Now you need to extend it — but the source code is either with the original vendor (refusing to release) or simply lost. You need a combination of reverse engineering and replacement.
You received the repository and credentials, but no documentation, no architecture overview and no one to ask. The system runs, but no one on your side can safely change it.
Stories combine common patterns across multiple rescue engagements. Specific client names, numbers, sectors and stack details are anonymised or composite. Not a guarantee of specific outcome.
No production deploy. We took over, shipped a first user-facing release, then reached full feature parity on a maintainable stack. Composite scenario across multiple rescue engagements.
After years building their internal CRM in Delphi. We ran a deep-dive, produced full documentation, then carried out a phased rebuild on a modern stack. Composite scenario.
A stalled ERP replacement. We ran a triage, recommended NOT finishing the rewrite but instead a phased modernisation around the old system. Composite scenario.
Examples combine recurring patterns from multiple rescue engagements. Specific client names, numbers, sectors and stack details are anonymised or composite. No guarantee of any specific outcome.
