How to Reuse Your Last Prototype Codebase Safely

Reusing a previous prototype codebase saves two to five days on the next project if the shared code is limited to infrastructure: input handling, scene management, build settings, and utility scripts. It costs more than it saves when game-specific logic carries over, because the new prototype bends to fit the old one instead of being designed on its own terms.

Why reuse is tempting and risky

The temptation is real. You spent a week building a working prototype, and the next concept needs the same input system, the same scene loader, the same analytics integration. Copying the project folder and starting from there feels like a head start.

The risk is that prototype code solves a specific problem quickly, not cleanly. Shortcuts that were acceptable in a one-week test become costs in the next project, and they compound because nobody remembers which parts were shortcuts.

The goal is to carry the hours of infrastructure work forward without carrying the hours of technical debt.

What is safe to reuse

Four categories of code survive reuse well.

Input abstraction. Touch handling, swipe detection, tap-versus-hold logic. These are game-independent and they take real time to get right. The work from Mobile Input Handling: Getting the Feel Right is reusable across projects.

Scene and state management. The code that loads scenes, transitions between them, and manages the game state machine. This is infrastructure that every project needs and that rarely changes between genres.

Build and platform configuration. Target settings, minimum spec, icon sizes, orientation locks. Recreating these from scratch is error-prone and pointless.

Utility scripts. Object pooling, coroutine helpers, extension methods, debug overlays. These are general-purpose and they improve with reuse because bugs get fixed across projects.

If the code does not know what game it is in, it is safe to reuse. If it does, it probably is not.

What is not safe to reuse

Three categories that should be stripped or rewritten.

Game-specific mechanics. The core loop logic, the scoring system, the level generation. These solve the previous game's design, and bending them to fit a different design takes longer than writing fresh code for the new one.

Temporary architecture decisions. Prototype code often has a "manager" class that does everything because refactoring was not worth the time. Carrying that class forward locks the new project into the old project's structure.

Hardcoded content. Difficulty curves, reward tables, level data. These are for the old game, and leaving them in place creates confusion about what is intentional and what is leftover.

The diagnostic is simple: if reusing a piece of code requires reading it carefully to understand what it does, it is cheaper to write fresh code that does what you actually need.

The audit checklist

Before starting a new prototype from an old codebase, run through this list.

1. Delete all game-specific scenes. Keep only a blank loader or bootstrap scene.
2. Delete all game-specific scripts. Anything that references a game mechanic, a specific UI layout, or content from the previous project.
3. Delete all content assets. Sprites, audio, prefabs. Keep only structural prefabs like a camera rig or an event system.
4. Check the input system. Verify it works generically. Remove any game-specific bindings.
5. Verify the build settings. Reset the bundle identifier, the product name, and any analytics keys.
6. Run it. The stripped project should launch to an empty scene with no errors. If it does not, something has a hidden dependency on removed code.
7. Check the packages. Remove packages the old prototype imported that the new one does not need. Each unused package adds build time and size, per Cut Your Unity Build Size in Half.

This audit typically takes two to four hours. If it takes longer, the codebase is too entangled and starting fresh is faster.

The two-day rule

If setting up the reused codebase, stripping the old code, and verifying everything clean takes more than two days, you have passed the break-even point. Starting a new project from a clean template would have been faster.

Two indicators that you are past the line.

• You are debugging interactions between old systems and new code. This means the old architecture is asserting itself, and you are now working around it rather than building on it.
• You are keeping old code "just in case." Commented-out code and unused scripts create noise that slows every search and every debug session for the rest of the project.

The two-day rule is a guideline, not a law. But teams that exceed it consistently find that they spent three days getting a reused codebase to a state that a clean start reaches in one.

Building a reusable template

The better version of codebase reuse is maintaining a project template that is already stripped.

A template is a Unity project (or a Godot project, depending on your engine) with nothing game-specific in it. It contains the infrastructure code, the build settings for your target platforms, and the packages you always use.

Update the template after each project. When a utility script improves, update the template. When a new package becomes standard, add it. When a setup step keeps tripping people up, automate it in the template.

Three components of a good template.

• A bootstrap scene that initialises the input system, the state machine, and any analytics or crash reporting.
• A folder structure that matches your team's conventions. Consistent folder layout across projects makes onboarding instant.
• A README listing what the template provides and what the new project needs to add.

The template approach is faster than reuse-and-strip for every project after the first, because the stripping is already done.

Version control considerations

Two rules for using version control with a reused codebase.

Start a new repository. Do not branch from the old project. A branch carries the full history, and that history is misleading because it describes a different game. A new repository with a clean initial commit makes the project's history its own.

Tag the template. If you maintain a template, tag the version each new project starts from. When a bug is found in the template, you can check which projects used the affected version.

The prototype workflow from The Seven-Day Prototype Process benefits directly from a clean template, because it removes setup time from an already tight schedule.

When starting fresh is better

Three situations where reuse is the wrong call.

1. Different engine or major version. If you are moving from Unity 2021 to 2023, or from Unity to Godot, the infrastructure code may not transfer cleanly. Porting time can exceed rebuild time.
2. Different genre with different needs. A runner prototype and a puzzle prototype share almost no game logic. The overlap is just infrastructure, and a template handles that better than a strip-and-reuse.
3. The old codebase was a mess. If the previous prototype was a rush job with no separation between systems, stripping it is archaeology. Start clean, but copy individual utility functions that you know work.

What we would do

Maintain a project template and update it after every shipped prototype. The template contains input handling, scene management, build settings, analytics integration, and utility scripts. Nothing else.

When starting a new prototype, copy the template into a new repository. Never branch from an old game project. The five minutes of setup time saved by branching costs hours of confusion later.

If you do not have a template yet, build one by stripping your best-structured previous prototype using the audit checklist above. That single effort pays for itself on the next project and every one after.

The short version

• Reuse infrastructure: input, scene management, build settings, utilities.
• Strip everything game-specific: mechanics, content, hardcoded data, and manager classes.
• Run the audit checklist. The stripped project should launch to an empty scene with no errors.
• If stripping takes more than two days, starting fresh is faster.
• Maintain a project template instead of reusing and stripping each time.
• Start a new repository for each project. Do not branch from the old one.

Build your template from your cleanest prototype this week. If you need help structuring a reusable project foundation, tell us about your setup.

Related reading: The Seven-Day Prototype Process, Mobile Input Handling: Getting the Feel Right, and Free Tools for Solo Devs Who Ship Faster.