Processes - System Rebuilds - Onboarding & Delivery Process

Overview

This process is for products that launched quickly and now need a stronger technical foundation.

That might mean:

• A vibe-coded MVP that has traction
• A no-code or low-code product that is hitting limits
• A codebase that has become too risky to extend
• A system the team has inherited and cannot work in confidently

1 - Rebuild intake

The process begins with the rebuild enquiry form.

The intake captures:

• What exists today
• What is breaking down
• What level of urgency and business pressure exists
• What technical access is available
• Which intro call slot works from the currently available options

2 - Fit review and intro call

After intake:

• I review the system context and likely rebuild shape
• I assess whether current capacity matches the timing
• I confirm the relevant rates if the engagement looks viable
• We use the intro call to clarify risk, continuity requirements, and likely rebuild sequencing

3 - Rebuild framing and access handover

If we move forward, the next step is to establish the rebuild foundation.

That typically includes:

• Confirming the business-critical parts of the current system
• Identifying what must be preserved during the transition
• Getting access to code, data, environments, or platform tooling
• Agreeing the immediate priority for the first phase of rebuild work
• Finalising the agreement and any onboarding admin

4 - Early rebuild work

The first working phase usually focuses on:

• Mapping the riskiest parts of the current system
• Identifying quick wins and dangerous assumptions
• Choosing the safest execution path
• Beginning implementation work that reduces risk without breaking continuity

5 - Ongoing rebuild rhythm

Once active, the rebuild runs with a simple delivery rhythm:

• Priorities stay visible
• Tradeoffs are surfaced early
• Progress is communicated clearly
• Existing user needs stay in view
• New architecture decisions stay connected to real delivery pressure

6 - Decision points during the rebuild

As the engagement progresses, we repeatedly decide:

• What gets preserved versus replaced
• Whether to expand the rebuild scope or keep it narrow
• Whether the engagement should stay time-based at the current level
• When the system is stable enough to shift into normal ongoing development

7 - Handoff, continuation, or expansion

At the end of a rebuild phase, one of three things usually happens:

• The rebuild is complete and handed over cleanly
• The product moves into ongoing development support
• A new phase is opened for the next layer of system work