Broken or half-built?
Let’s finish it.

• It crashes, loses work, or breaks at the worst moment.
• A developer left, and the project stopped halfway.
• An app built with AI coding tools works in the demo but falls apart in real use.
• It worked once, but no longer fits how you work.

Often, but that’s decided from evidence, not assumed. The first step is running the software and reading the code. You get a plain answer: what can stay, what should be repaired, and what, if anything, is worth rebuilding, with the reasons.

1. 01

   Share What You Have

   The code or access to it, what the software should do, and the steps that show the problem.

2. 02

   Assessment

   The software is run and read to find what works, what doesn’t, and why.

3. 03

   Written Plan and Fixed Quote

   What will be repaired or finished, how it will be checked, and the price. Work starts only when you approve it.

A prototype built with AI coding tools may demonstrate the idea while leaving saving, recovery, dependency setup, validation, or testing unfinished. The assessment identifies what actually exists and what needs to change before extending it.

The fix starts with tests and structure, not a rewrite by default.

Webs, PhreeLabs’ game engine, had repeated one-second freezes on the development Mac. Profiling traced them to waits for a Metal drawable inside SDL. After switching the Mac build to SDL’s OpenGL renderer, a 120-input test showed 0 one-second stalls in 597 frames. See the Webs page.

A useful repair starts with a failure that can be reproduced. Describe the intended behavior, the steps that break it, and what is at risk when it fails.

First Decision

Assess whether the source can be built and run, which dependencies are available, and whether a targeted repair is practical. The diagnosis informs the build scope.

Repair Evidence

Record the conditions before the change and repeat the same check afterward. Relevant nearby behavior should still work.

Value Check

Consider the disruption removed, the usable work recovered, and the remaining maintenance burden. A technically repairable system is not always worth extending.

The Webs renderer investigation is a documented in-house example, with its test conditions stated. It is not a client recovery result.

The repaired or completed software, a plain-language list of what changed, and tests for what was fixed.

Bugs in what was delivered are fixed free for 30 days after handoff. Ongoing support and new features are quoted separately.

• What the software should do
• Where it fails or what’s missing, with the steps that show it
• What it’s built with and where it runs, if you know
• Whether the source code is available