Das Projekt wurde übernommen
Die Verantwortung hat gewechselt, die Dokumentation ist unvollständig und die tatsächlichen Abhängigkeiten sind unklar.
Unity-Projektprüfung & Reparaturen
Probleme mit Ihrem Unity-Projekt? Finden Sie heraus, was repariert werden muss.
Sie haben ein Unity-Projekt übernommen, der bisherige Entwickler ist nicht mehr da oder das Spiel beziehungsweise die App läuft nicht mehr? Ich prüfe den Quellcode, die Schritte zum Starten und die betroffenen Geräte und erkläre, was repariert werden muss. Ihr Team kann den Bericht nutzen, oder wir vereinbaren die Reparaturen gemeinsam.
20–40hTypische erste Bewertung
Zuerst den Build herstellenBelege vor Versprechen
NDAVor vertraulichem Zugriff
PraktischBehebung möglich
Wann Sie hier beginnen sollten
Das Projekt existiert. Das Vertrauen fehlt.
Eine Prüfung hilft, wenn Sie über Reparaturen oder weitere Entwicklung entscheiden müssen, aber noch kein verlässliches Bild vom Zustand des Projekts haben.
Der Build ist fragil
Es funktioniert auf einem Rechner, scheitert in CI oder hängt von undokumentierter lokaler Einrichtung und manuellen Schritten ab.
Leistungsprobleme blockieren die Veröffentlichung
Frame-Zeit, Speicher, Ladeverhalten, Abstürze oder gerätespezifisches Verhalten brauchen eine Diagnose anhand von Belegen.
Integrationen fallen immer wieder aus
Anbindungen an Serverdienste, externe Werkzeuge, Telefonfunktionen, Steam oder VR-Geräte verursachen wiederholt Probleme bei der Vorbereitung eines Updates.
Änderungen haben unvorhersehbare Auswirkungen
Eng gekoppelte Systeme machen kleine Korrekturen teuer und anfällig für Regressionen.
Der Fahrplan beruht auf Vermutungen
Das Team braucht eine belastbare Entscheidung zum Fertigstellen, Refaktorieren oder Neuaufbauen, bevor es den Aufwand ausweitet.
Konkrete Ergebnisse
Wissen, was funktioniert. Entscheiden, was behoben werden soll.
Die Bewertung richtet sich danach, was der Produktverantwortliche entscheiden muss und was das Entwicklungsteam als Nächstes umsetzen muss.
- 01
Was funktioniert und was den Start des Projekts verhindert
Build-Status, Hinweise zur Umgebung und klar dokumentierte Blockaden.
- 02
Architekturübersicht
Kernsysteme, Abhängigkeiten, Verantwortungsgrenzen und kritische Kopplungen.
- 03
Priorisiertes Risikoverzeichnis
Befunde, priorisiert nach Auswirkung, Wahrscheinlichkeit und Dringlichkeit für die Auslieferung.
- 04
Befunde zu Leistung & Integrationen
Messbare Belege von der relevanten Plattform, dem Gerät oder Headset.
- 05
Technische Richtung
Eine begründete Empfehlung zum Fertigstellen, Refaktorieren oder Neuaufbauen – keine reflexartige Neuentwicklung.
- 06
Ein Reparaturplan mit klaren Etappen
Meilensteine, Abnahmekriterien, Abhängigkeiten und sinnvolle nächste Entscheidungen.
Die Prüfung konzentriert sich auf die wichtigsten vereinbarten Fragen. In 20–40 Stunden lassen sich nicht alle Fehler eines großen bestehenden Projekts finden. Der Bericht erklärt deshalb auch, was geprüft wurde und was noch unklar ist.
So läuft die Bewertung ab
Den Arbeitsbedarf verstehen, bevor Sie in Reparaturen investieren.
- 01
Briefing & Zugriff
Klären Sie Produkt, Zielplattform, aktuelle Blockade und Erfolgskriterien. Vereinbaren Sie bei Bedarf vor dem Repository-Zugriff eine NDA.
- 02
Prüfen, ob das Projekt läuft
Das Projekt ausführen, das Problem reproduzieren und den tatsächlichen Build-Weg dokumentieren, bevor Lieferzusagen gemacht werden.
- 03
Untersuchen & messen
Architektur, Abhängigkeiten, Datenfluss, Integrationen und Leistung auf dem relevanten Ziel verfolgen.
- 04
Entscheiden & ordnen
Empfehlen, was zuerst repariert werden sollte, die Möglichkeiten erklären und anhand der Ergebnisse eine überschaubare erste Aufgabe vorschlagen.
Die zentrale Entscheidung
Fertigstellen, refaktorieren oder neu aufbauen?
Die Antwort sollte Produktvorgaben und Belegen folgen – nicht Geschmack, Panik oder bereits versenkten Kosten.
Fertigstellen01
Den funktionierenden Kern erhalten.
Wenn die Architektur brauchbar ist, konzentrieren Sie den Aufwand auf Blockaden, Validierung und veröffentlichungskritische Lücken.
Refaktorieren02
Die Teile verbessern, die Probleme verursachen.
Wenn bestimmte Module Risiken erzeugen, isolieren und reparieren Sie sie, ohne das gesamte Produkt zu destabilisieren.
Neu aufbauen03
Nur einsetzen, wenn Belege dafür sprechen.
Eine Neuentwicklung ist erst vertretbar, wenn die bestehende Struktur das erforderliche Produktergebnis nicht erreichen kann.
Relevante Belege
Praktische Umsetzungserfahrung hinter der Bewertung.
Architekturentscheidungen basieren auf praktischer Produktentwicklung: veröffentlichte PCVR-Titel, produktive mobile Software und Spiele mit umfangreichen Systemen.
Auf Steam veröffentlichtes PCVR
Reach The Beat
Alleiniger Unity-Entwickler und technischer Verantwortlicher für Architektur, Gameplay- und XR-Systeme, Tools, Builds, Hardwarevalidierung und Veröffentlichung.
Steam-Beleg ansehenProduktives Android / iOS
Vertrauliches Mobilprodukt
Alleiniger Unity-Client-Entwickler und Mobile-Architekt für komplexe UI, backendabhängige Abläufe, Gerätevalidierung und native Integrationen.
Produktidentität nicht offengelegt · NDA-konform
Systemreiche Spiele
Vernetzte Produktsysteme
Architektur und Implementierung für Fortschritt, Spielstände, Lokalisierung, Analysen und datenbasierte Inhaltssysteme.
Über 5 Jahre kommerzielle Unity-Erfahrung · Öffentliche Upwork-Bewertung: 5,0
Fragen vor dem Zugriff
Klare erste Schritte.
01Können Sie ein bestehendes oder aufgegebenes Unity-Projekt übernehmen?
Ja. Ich prüfe zunächst, ob das Projekt läuft, sehe mir den Code an und ermittle, was repariert oder wiederverwendet werden kann. Vor der Aufwandsschätzung für größere Entwicklungsarbeiten empfehle ich einen ersten Schritt.
02Welchen Zugriff benötigen Sie?
Für die Bewertung selbst meist: Repository, Unity-Version, repräsentativer Build, verfügbare Dokumentation sowie Zugriff auf die Zielplattform oder Informationen zur Hardware. Beginnen Sie mit einem groben Überblick. Vor sensiblen Details oder Repository-Zugriff können wir eine NDA vereinbaren.
03Zeigt uns die Bewertung, ob wir fertigstellen, refaktorieren oder neu aufbauen sollten?
Das ist eines der Hauptziele. Die Empfehlung orientiert sich an Belegen, Produktvorgaben, Auslieferungsrisiken und der Definition von Erfolg – nicht an einer pauschalen Vorliebe für Neuentwicklungen.
04Können Sie den Fahrplan nach dem Audit umsetzen?
Ja. Ihr Team kann den Bericht verwenden, oder wir vereinbaren separat Fehlerbehebungen, gezielte Codeverbesserungen, Leistungsoptimierung, Dienstanbindungen oder Veröffentlichungsvorbereitung. Die Prüfung verpflichtet Sie zu keiner weiteren Arbeit.
05Wie umfangreich ist die erste Zusammenarbeit?
Wir beginnen mit einer bezahlten Prüfung. Bei einem übernommenen Projekt oder unklaren Problemen können 20–40 Stunden sinnvoll sein. Stunden, Honorar, Hauptfragen und Bericht vereinbaren wir vor Beginn. Sie erhalten eine Dokumentation dessen, was funktioniert oder den Start verhindert, die wichtigsten Risiken und eine vorgeschlagene erste Reparaturphase. Entwicklung wird separat geschätzt.
Mit der Blockade beginnen
Erzählen Sie mir, was immer wieder ausfällt.
Begrenztes Budget? Nennen Sie mir Ihre Priorität und den Rahmen, mit dem Sie sich wohlfühlen. Ich sage klar, welcher erste Schritt realistisch ist.
Vertraulich ab dem ersten Gespräch
Ich zähle Kontaktaktionen nur zusammengefasst, ohne Besucher-IDs oder Nachrichteninhalte.
Brauchen Sie eine andere Art von Unterstützung?
Alle LeistungenEin Spiel entwickeln
Spieleentwicklung
Eine App außerhalb des Spielebereichs entwickeln
App-Entwicklung
Ein Produkt voranbringen
Technische Unity-Leitung in Teilzeit
Ein Produkt wiederbeleben & erneut testen
Updates & Betreuung für ältere Unity-Projekte
KI mit einem realen Arbeitsablauf verbinden
KI-Anbindungen & Erprobung privater KI
Die passenden Kompetenzen zusammenbringen
Entwicklung mit Kreativ- und Testspezialisten
Qualität vor dem nächsten Schritt prüfen