H-Studio logo
ENDE
Start a project
Berlin Studio · Software Rescue & Project Takeover

Your software project is stuck.
We take over from here.

We establish what still works, secure the available access and give you a written recovery decision. You keep the findings, whether we continue or another team takes over.

Failed handover · Lost access · Stalled delivery· Berlin · DACH
Engagement
Mutual NDA before technical access
Triage
Access, deployability, data, code, infrastructure and handover
Output
Written recovery decision and priority map
Capacity
Confirmed before technical access begins
Selected H-Studio clients and projects across DACH and global engagements
My Office AsiaForschungsmittelVulken FMGRIDWenzelFolluMy Office AsiaForschungsmittelVulken FMGRIDWenzelFollu
Typical starting points · 01

Where rescue work starts.

Four common reasons a team needs an independent technical decision.

01

Failed external delivery

An external team stopped responding, delivered unstable software or never shipped. Management needs an independent decision on what can move forward.

Repository accessProduction stateHonest scope read
02

Departed developer

A developer or small team left with most of the system knowledge. The software still matters, but nobody can safely change or release it with confidence.

Knowledge recoveryBaseline documentationStabilise & onboard
03

Stalled rewrite or migration

A rewrite or migration has consumed time without reaching production. Leadership now needs a reasoned choice between finishing, salvaging and stopping.

Outside readSalvage vs rebuildPhased recovery plan
04

Unresponsive or insolvent supplier

The supplier is unavailable or the handover failed. Repository, hosting and deployment ownership must move under your control through authorised access.

Controlled handoverRepository & infrastructure accessContinuity plan
When this fits — and when it doesn't · 02

A technical problem we can assess responsibly.

We can assess engineering risk and establish a recovery path. We cannot replace ownership evidence, legal advice or access authority.

Good fit when
  • Your organisation owns the product or is authorised to act for the owner.
  • Some technical evidence is available, or there is a lawful route to restore access.
  • A decision-maker can align business priorities with the technical findings.
  • You are prepared for the recommendation to be recover, rebuild or stop.
Less of a fit when
  • You need ongoing maintenance of a healthy system — that is Platform Support, not a rescue.
  • The main issue is a contract, licence or IP dispute — that requires qualified legal advice.
  • No authorised person can grant access to the systems or available artefacts.
  • You need a recovery guarantee before the evidence can be reviewed.
What you get from the assessment · 03

An initial triage answers: is this recoverable?
A written deep-dive answers: what does recovery look like?

The assessment creates usable evidence before any larger engineering commitment.

01

Access and ownership map under NDA

We confirm who controls the repository, hosting, deployments and critical accounts. Missing access is documented with a recovery route and ownership checks; nothing is promised before the available evidence is known.

02

Six-axis technical triage

Security exposure, deployability, data integrity, code quality, infrastructure and handover viability are reviewed. Each area receives a concise finding and confidence note, so uncertainty remains visible.

03

Recovery decision and priority map

You receive a reasoned recover, rebuild or stop decision, followed by the first critical actions in order. The logic is explicit enough for management and another engineering team to use.

04

Written deep-dive recommendation

Where deeper analysis is commissioned, we document architecture, technical debt, critical fixes and recovery options in one transferable report. It becomes the working brief for whichever team continues.

05

No-lock-in by design

All findings, priorities and recovery documentation remain yours. Continue with H-Studio, hand the material to an internal team or appoint another supplier without repeating the diagnostic.

Delivery path · 04

From controlled access
to a recovery decision.

Each step has a clear output and approval point. Continue only when the next step is justified.

Step 01

Access and technical framing

  • Mutual NDA before any access
  • Coordinate repository, server and infrastructure handover
  • Map what access exists and what still needs to be recovered

A clear picture of what you actually hold and a controlled path to the rest. Where access is incomplete, we say so plainly.

Step 02

Initial triage

  • Six-axis technical read (security, deployability, data integrity, code quality, infrastructure, handover)
  • Short written read per axis with a confidence note
  • Written summary and a call

An honest read on whether the system is recoverable, in writing, that you can share internally.

Step 03

Written recovery recommendation

  • Architectural audit and technical-debt inventory
  • List of critical fixes and a priority map
  • Recommendation: recover, partial rebuild, full rebuild or stop

A hand-off-able recovery recommendation you can give to any technical team — ours or another.

Step 04

Optional continuation

  • Take-over and stabilisation of the system
  • Phased recovery or parallel rebuild
  • Senior engineering lead throughout

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.

Patrick, Co-Founder · Client Lead at H-Studio Berlin
Patrick · Co-Founder · Client Lead
Direct contact · 05

Clear communication from the first conversation onward.

Patrick is your main point of contact. He keeps communication focused, brings the right engineers into each conversation and makes sure decisions are explained in plain language.

Technical conclusions come from the engineers working on the system. Patrick keeps priorities, responsibilities and next steps clear from one stage to the next.

· Direct contact· Engineering input· Clear next steps· No lock-in
Cases · 06All cases →→

Related engineering work.

Four plates from the studio archive — one unfolded, three pinned beside it. Each is a real production system, not a case-study template.

Featured case
B2B SaaS · Startup

Creator Marketing Platform

Platform recovery & rebuild

Read full case
Enterprise · DE

Vulken FM

Enterprise facility management

Read case→
Mittelstand · DE

Wenzel Group

Industrial B2B platform & tooling

Read case→
FAQ · 07

Rescue questions
we get most often.

What determines the scope of a rescue engagement?

The first step is deliberately narrow: confirm lawful access, identify the available evidence and run an initial technical triage. Codebase size, integrations, environments and operational risk determine whether a deeper review is needed. Every additional step is scoped in writing before it begins.

What if the previous contractor refuses to hand over the code?

We document what is available and coordinate a technical transfer with the people authorised to release it. Contract, licence and IP questions belong with qualified counsel, and we do not bypass access controls. Technical recovery proceeds only from systems and artefacts your organisation may lawfully use.

What if we don't have access to our own server anymore?

We first verify account ownership and use the provider's documented recovery process. If primary access cannot be restored, we assess authorised backups, deployment artefacts and other copies. The available evidence determines what can be recovered; no outcome is guaranteed in advance.

What if there's no documentation at all?

Where access allows it, the assessment creates a practical baseline: system map, deployment path, critical dependencies and known gaps. The exact documentation set is agreed with the review scope and remains yours.

What if the codebase is in a language nobody uses anymore (Delphi, Perl, ColdFusion, VB6)?

We first establish whether the relevant expertise, build tooling and operational access still exist. The realistic options may be temporary maintenance, risk containment, phased replacement or a parallel rebuild. The recommendation depends on business continuity and the evidence in the system.

What's the difference between the initial triage and the deep-dive?

Initial triage establishes whether a credible recovery path exists and which risks need immediate attention. A commissioned deep-dive turns that into a documented architecture and debt assessment, priority map and recover, rebuild or stop recommendation.

Do you take over and rebuild, or only assess?

Both are available. After the deep-dive you decide: keep the written recommendation and hand it to another team, or continue with us into stabilisation and recovery. We never make continuation a condition of the assessment.

What if the project is genuinely unrecoverable?

Sometimes the honest answer is 'don't continue this codebase, rebuild from the requirements instead.' If that's the conclusion, we say so in the deep-dive recommendation. We'd rather lose the larger engagement than recommend salvaging a project that isn't worth salvaging.

Contact · 08

Tell us what is stuck. We confirm fit and capacity before requesting technical access.

Describe the current status, what is blocked and who still controls access. Do not send credentials, source code or sensitive production data through the form or messaging channels. A mutual NDA is agreed before technical access.

H-Studio Berlin
Schmidstraße 2F-K · 10179 Berlin
Business-hours response · Berlin time
great

Let's build something great together