The project was inherited
Ownership changed, documentation is incomplete, and the real dependency map is unclear.
Unity project review & repairs
Taken over a Unity project, lost your previous developer or found that the game or app no longer works? I check the source code, how to run the project and the affected devices, then explain what needs fixing. You can use the report with your team or agree the repairs with me.
When to start here
A review helps when you need to decide what to fix or develop next but do not yet have a reliable picture of the project’s condition.
Ownership changed, documentation is incomplete, and the real dependency map is unclear.
It works on one machine, fails in CI, or depends on undocumented local setup and manual steps.
Frame time, memory, loading, crashes or device-specific behavior need evidence-led diagnosis.
Connections to server services, third-party tools, phone features, Steam or VR devices keep causing problems when you prepare an update.
Tightly coupled systems make small fixes expensive and regression-prone.
The team needs a defensible finish, refactor or rebuild decision before scaling effort.
Concrete deliverables
The assessment is structured around what the product owner needs to decide and what the engineering team needs to execute next.
Build status, environment notes and clearly recorded blockers.
Core systems, dependencies, ownership boundaries and critical coupling.
Findings ranked by impact, likelihood and delivery urgency.
Measured evidence from the relevant platform, device or headset.
A reasoned finish, refactor or rebuild recommendation—not a reflexive rewrite.
Milestones, acceptance criteria, dependencies and useful next decisions.
The review focuses on the most important questions we agree. A 20–40-hour review cannot find every bug in a large existing project, so the report also explains what was checked and what remains uncertain.
How the assessment works
Clarify the product, target platform, current blocker and success criteria. Arrange an NDA before repository access when needed.
Run the project, reproduce the issue and document the actual build path before making delivery promises.
Trace architecture, dependencies, data flow, integrations and performance on the relevant target.
Recommend what to fix first, explain the options and suggest a manageable first piece of work based on the findings.
The core decision
The answer should follow product constraints and evidence—not taste, panic or sunk cost.
When the architecture is serviceable, focus effort on blockers, validation and release-critical gaps.
When specific modules create risk, isolate and repair them without destabilizing the whole product.
A rewrite becomes defensible only when the current structure cannot meet the product’s required outcome.
Relevant proof
Architecture decisions are grounded in hands-on product delivery across shipped PCVR, production mobile software and systems-heavy games.
Shipped Steam PCVR
Sole Unity engineer and technical owner across architecture, gameplay and XR systems, tooling, builds, hardware validation and release.
View Steam proofProduction Android / iOS
Sole Unity client engineer and mobile architect for complex UI, backend-dependent flows, device validation and native integrations.
Product identity withheld · NDA-safe
Systems-heavy games
Architecture and implementation across progression, saves, localization, analytics and data-driven content systems.
5+ years commercial Unity · 5.0 public Upwork rating
Questions before access
Yes. I first check whether the project runs, review its code and identify what can be repaired or reused. I recommend a first step before estimating a larger piece of development.
For the assessment itself: usually the repository, Unity version, a representative build, available documentation and access to the target platform or hardware context. Start with a high-level outline. We can agree an NDA before you share sensitive details or grant repository access.
That is one of its main purposes. The recommendation is tied to evidence, product constraints, delivery risk and the definition of success—not a blanket preference for rewrites.
Yes. Your team can use the report, or we can separately agree work on fixes, selected code improvements, performance, service connections or release preparation. The review does not commit you to further work.
We start with a paid review. For an inherited project or one with unclear problems, 20–40 hours may be appropriate. We agree the hours, fee, main questions and report before starting. You receive a record of what works or prevents the project from running, the most important risks and a proposed first repair stage. Development is estimated separately.
Start with the blocker
Have a limited budget? Tell me your priority and the range you’re comfortable with. I’ll be clear about a realistic first step.
Confidential from the first conversation
I count contact interactions in aggregate, without visitor IDs or message contents.
Build a game
Build a non-game app
Keep a product moving
Revive & retest a product
Connect AI to a real workflow
Bring the right skills together
Check quality before the next step