01
The project has been dormant
The original developer has moved on, dependencies have aged or the build no longer works. You need to understand what is recoverable before investing in a new release.
Updates & Support for Older Unity Projects
I repair, update and support older Unity games and apps. I can get a stalled project running again, improve its screens and features, and add tracking to understand how people use it. We agree the work, cost and expected result before each stage.
When this fits
01
The original developer has moved on, dependencies have aged or the build no longer works. You need to understand what is recoverable before investing in a new release.
02
The main features work, but old screens, confusing first steps, device problems or missing connections to other services make the product harder to use.
03
You have a hypothesis and need a focused update, reliable product events and a real-user test to decide whether to continue, adjust or stop.
What you receive
Build recovery, dependency review, targeted fixes and staged Unity or SDK upgrades where justified. Document setup, release steps and remaining risks; check existing saves and data flows where relevant.
Improve the agreed screens, first-use instructions, gameplay or app features. Check that layouts fit the intended devices and address agreed speed or responsiveness problems. Choose changes that answer a clear question about how people use the product.
An event plan, agreed SDK integration, event validation and reporting setup for activation, progression, returning users and technical quality. Include version context and required consent controls in the implementation scope.
Test builds, release preparation, agreed attribution or campaign-link integrations, and a measurement checklist. Follow with a review of the available evidence and a prioritized next step.
I own the agreed engineering and measurement implementation. Visual assets, specialist design, marketing campaigns and paid acquisition need separate scope and clear owners. I can prepare the product and tracking for promotion and work with your marketer; retention gains, audience growth, revenue and store approval are not guaranteed.
A relaunch is a test, not a promise
A modern look can be part of the hypothesis. Product analytics helps you examine what people actually do—not just whether the update looks better. For non-game applications, activation or successful task completion may be more useful than daily return rates.
For example: make the first session easier to complete, remove a progression bottleneck or reduce loading friction. Choose the question before choosing the update.
Define what each event means, check that it fires correctly and separate test traffic from real users. Installing an analytics SDK is only part of the work.
Agree who will use the test and how they will reach it. Wait for the relevant return window; a small or unrepresentative sample may not support a decision.
| Signal | What to track | The question it supports |
|---|---|---|
| Activation & onboarding | Tutorial steps, first meaningful action and early-session exits. | Where do people get stuck before experiencing the core value? |
| Returning users | D1 / D7 retention for defined new-user cohorts, where relevant. | Do users return on the measured day after their first use? |
| Technical quality | Crashes, loading time and device-specific performance alongside usage. | Is technical friction preventing a fair test of the product? |
| Test context | Build version, platform, audience and acquisition source where available. | Are we comparing similar users under comparable conditions? |
The first instrumented release shows where the product stands; it cannot reconstruct retention from an untracked release. Agree the cohort and return-event definitions before testing. Compare equivalent observation windows and record audience differences. A before-and-after change alone does not establish that the refresh caused an improvement.
How we work together
Reproduce the build, review dependencies and existing data, and identify what is safe to keep. Agree a feasibility checkpoint before a larger commitment.
Choose the product hypothesis, target audience, success measures, observation window and stop criteria. Assign an owner for test-user recruitment or traffic.
Make the agreed changes, check usage tracking and test the chosen devices. Where relevant, check that existing users can update without losing saves or data. Record the version being tested and how its results will be measured.
Review the test after the agreed observation window. Separate product signals from technical issues and missing data, then choose whether to iterate, maintain or pause.
Relevant development experience
This offer builds on hands-on product engineering across shipped games, analytics systems and production mobile UI. These are relevant engineering examples—not claims of a measured relaunch or retention uplift.
Production Android / iOS
As sole Unity client engineer and mobile architect, I built responsive Figma-driven UI, asynchronous navigation, backend-dependent flows and native integrations, with device validation. Product details remain confidential.
Product identity withheld · NDA-safe
Systems-heavy games
As the sole Unity developer and systems architect, I designed analytics alongside gameplay, progression, economy, save and data-driven content systems, integrating the team’s art, audio, game design and balance work.
Explore the engineering portfolioBefore we start
A project review identifies problems, reusable work and recommended next steps. This service also covers making the agreed repairs and updates, adding usage tracking and preparing a version for testing. We can start with a review before deciding what to change.
Yes. Scope can be limited to maintenance, compatibility fixes, integrations or a staged upgrade. Follow-on maintenance and iteration are agreed separately, including response times and responsibilities; this is not an implied 24/7 operations service.
No. I review the current project and target requirements first, then choose a compatible, maintainable path. A staged upgrade or focused refactor may be enough. Source access, asset rights, service availability and store-account access can limit what is feasible.
Only if the data allows a fair comparison. If earlier tracking was unreliable, the first release with tracking gives us a starting point for future comparisons. We need similar groups of users or a carefully planned experiment. Too few users, different audiences or a short test can leave the answer unclear.
I can prepare builds, tracking and agreed attribution integrations for a relaunch, and coordinate the technical side with you or your marketer. Audience recruitment, advertising management, creatives and ad spend are not included by default. If there are no users, we need a separate plan for reaching them before a retention test can be useful.
Yes. I can build updated screens from Figma designs, make layouts fit different screen sizes and improve first-use guidance and interactions. I can work with your designer or bring in trusted artists. We agree specialist availability, work and fees separately.
Discuss updates & ongoing support
Tell me about the game or app, what no longer works and what you want to change. We can start by checking the project and agreeing a manageable first repair or update.
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
Improve an existing product
Keep a product moving
Connect AI to a real workflow
Bring the right skills together
Check quality before the next step