Skip to main contentSkip to service detailsSkip to contact
Ocean View Games
Unity Project Rescue and Takeover

Unity Project Rescue and Takeover

Get a stalled or inherited Unity project moving again. We assess the codebase, stabilise the build and agree a recovery plan based on what can be retained and what needs changing.

Domi Online, a live Unity MMO with over 1,000 concurrent users
Domi Online logo

From code review to ongoing engineering on Domi Online

Developed by Ocean View Games as the client's core technical partner.

Our involvement in Domi began with a technical code review during the earliest stages of development. We were then brought in to lead engineering across networking, backend, gameplay and tooling.

That progression from assessment to technical ownership informs our recovery work: understand the existing systems, agree the next milestone and make changes in a controlled sequence.

An unfinished brief is fine. The first conversation helps establish scope.

What are you starting with?

If any of these describes your situation, the diagnostic is the right first step. We do not need a polished brief or a tidy repo to start.

Your previous studio went quiet

Missed milestones, went dark or shut down, and you are holding a codebase you cannot fully account for.

Book a diagnostic

Nobody can compile the project

The original lead left, the build works on one machine and nowhere else, or dependencies have gone missing.

Start a project brief

You need a build for a pitch

There is a publisher pitch or funding milestone coming and the codebase is not in a state to demo.

Explore co-development

How project rescue works

Three phases. The first is a fixed price and a fixed deliverable. The second and third only happen if the diagnostic recommends them and you agree to proceed.

  1. 1. Diagnostic week

    David personally audits the codebase, runs profiling, identifies the critical risks and produces a written diagnostic with three options, finish, refactor or rebuild, and honest cost estimates for each. The diagnostic is scoped separately, with no obligation to commission the recovery.

  2. 2. Stabilisation

    Work towards a build that the team can develop reliably: the build fixed across machines, lost dependencies restored, critical performance regressions addressed and the systems documented.

  3. 3. Forward delivery

    A standard co-development engagement scoped to whatever is left to ship: agreed milestones, weekly demos, paid in arrears.

What we establish before recovery begins

A recovery plan needs to account for the code, the remaining work and the people who know the project.

A reproducible build

Identify the Unity version, dependencies, missing assets and build steps so the project can run on the agreed development machines.

What can be retained

Assess working systems and incomplete features. We explain where a focused fix, refactor or rebuild is justified, with the evidence behind the recommendation.

Release priorities

Separate blockers from improvements that can wait. Agree what a usable milestone contains and which features need to be deferred or reconsidered.

Handover from the previous team

Where possible, review the project with the people who built it. Capture design decisions, deployment steps and known issues before that knowledge is lost.

Technical ownership

You work directly with David and Adam on the engineering decisions. We agree responsibilities and review points with your team before implementation.

Access and confidentiality

Agree confidentiality, repository access and the materials needed for the diagnostic before sharing the project.

Working together

Start with a conversation about what has gone wrong, what state the project is in and what still needs to ship.

The diagnostic week is the real first step. It is fixed price, delivered by the engineer who would lead the recovery, and it ends with a written recommendation you can act on with or without us.

From stabilisation onward it looks like any co-development engagement: agreed milestones, weekly demos, paid in arrears, senior engineers only.

You speak to David and Adam directly throughout, with technical decisions and progress reviewed together.

Meet the team
Frequently Asked Questions
We confirm availability after an initial conversation and review of the access required. The first stage is a separately scoped diagnostic of the Unity project. You receive a written recommendation before committing to stabilisation or further development.
The diagnostic explains which work is essential and whether a smaller release or phased recovery is practical. If the available budget cannot support a viable recovery, we say so. You can keep the report and use it to plan a later stage or brief another team.
Yes, where that helps the project. We can arrange a technical handover, work alongside the existing team or take over agreed responsibilities. Access, decision-making and ownership of each area are established before recovery begins.
Yes. We agree confidentiality before code or private project material is shared. We can review your NDA template or provide our own.
Our project rescue service focuses on Unity. If the game uses another engine and needs rebuilding in Unity, our legacy modernisation service may be more appropriate, subject to a feasibility review.
David Edgecombe and Adam Kaye stay involved in technical decisions and delivery. David is a Unity Certified Expert and previously worked as a Technical Developer on RuneScape Mobile at Jagex. You can read their individual experience on our team page.

Have a Unity project that is stuck?

Tell us what has gone wrong, what state the project is in and what still needs to be delivered. We will help determine a sensible next step.

Discuss your project

Prefer to organise your ideas first? Build a project brief.