Improve the prototype or rebuild it?

Define the next stage before judging the code

Start with the product you need next. Which user journey needs to become more dependable? What feature matters now? What data must remain intact?

Without a concrete goal, a rebuild can become an attractive way to postpone difficult decisions. Use the next useful outcome as the test for every proposed change.

Separate local problems from structural ones

An unreliable integration or a confusing module may be a bounded problem. A targeted repair could make the product much easier to use without replacing the rest.

Problems are more structural when simple changes repeatedly cross unrelated parts of the app, ownership of data is unclear, or the same rule is implemented differently in many places. Describe the pattern with examples instead of treating the whole codebase as one problem.

Try a small, meaningful repair

Choose one issue that matters to users. Work out where it belongs, make a bounded change, and check the behavior it affects. Record what was easy, what was surprising, and what prevented a confident release.

This gives you evidence about the application’s real change cost. If a focused repair works, you may have a path for improving the existing product. If it keeps uncovering the same underlying constraint, that helps locate the part that needs deeper work.

Consider replacing a part before the whole

You can often improve a product in stages: replace a fragile integration, separate a background task, clarify one data boundary, or introduce a better release process.

A partial replacement still needs care. Define what it owns, how it connects to the rest of the application, and how you will know it behaves correctly. The value comes from a clearer boundary, not merely newer technology.

Make a rebuild earn its place

Compare the options using the same questions: what does each approach enable, what existing behavior must be preserved, what could be lost, and how will users keep working during the change?

A broader rebuild may be justified when the required product cannot be reached safely or economically through smaller changes. It still needs an explicit plan for existing data, behavior, deployment, and the transition. Rewriting does not remove those responsibilities.

Choose a sequence you can explain

The outcome might be a repair plan, a staged replacement, or a carefully scoped rebuild. Write down why that approach fits the product’s next stage and what evidence could change the decision.

ALRN’s assessment is designed to make that choice clearer. You receive findings and a prioritized plan you can use with us, another team, or to guide your own next steps.