Unity & UE5 performance optimization and game rescue

Sound familiar? The symptoms checklist

• Frame drops in busy scenes — the game "feels cheap" and reviews say so.
• Memory spikes and crashes on mid-range Android devices your players actually own.
• Overheating and battery drain after ten minutes of play.
• A build that's ballooned past 200 MB, hurting install conversion.
• Garbage-collection hitches — a stutter every few seconds that nobody can pin down.
• A stalled project: the original developer left, the codebase is unfamiliar, and the launch date isn't moving.

Every one of these is diagnosable. None of them should be guessed at.

How we work: profile first, fix in priority order

The most expensive performance mistake is optimizing before you measure. The bottleneck is almost never where you think it is — so we profile on the actual devices your players use, not a dev machine, before touching a single system. Then we fix in measured priority order: the biggest frame-time win first, re-profile, repeat. You see the numbers at every step, not a promise.

Two more mistakes we see constantly (and fix):

• Death by a thousand cuts. One unbatched material. One texture at the wrong compression. One Update() doing string work every frame. Each is invisible alone; together they eat your frame budget alive.
• Letting the frame rate slip "just for this level." Players feel 45 fps as "this game feels cheap" long before they can name why — and they don't come back to tell you.

The usual culprits

• Draw calls & batching — too many unique materials and objects breaking batches, especially in UI-heavy scenes.
• Texture & memory budgets — uncompressed or oversized textures quietly consuming the memory mid-range devices don't have.
• GC spikes — allocations in hot loops (string building, boxing, per-frame LINQ) causing the periodic stutter.
• Physics — too many active colliders, expensive collision layers, physics running where a trigger would do.
• Build size — unused assets, duplicate content and debug payloads inflating the download.

Rescue: how taking over a stalled project works

1. Audit. We get the project building, run it, profile it, and map what's done, what's broken and what's missing. You get a written assessment, not a vibe.
2. Plan. A finish-line plan with milestones and a fixed scope for each — what ships, in what order, and what it costs. No open-ended hourly meter.
3. Finish. We work the plan in playable milestones until the game is shippable — the same process we use on full builds for clients across Canada and the US.

Honest expectations

Optimization recovers a lot: most games we profile have 20–40% of their frame time in a handful of fixable causes, and build size usually shrinks meaningfully once the payload is audited. What it can't do is repeal architecture — if a game's core design assumes hardware your players don't have, we'll tell you exactly that, show you the measurements, and lay out the real options (retarget the settings, rework the scene budget, or scope down the feature) instead of selling you hours. That honesty is the service.