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, delivery shape, and communication rhythm 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 in a structured weekly rhythm.

Daily — every working day: A morning touchpoint (planned focus, any blockers, what I need from you) and an afternoon or end-of-day touchpoint (progress made, decisions taken, what's next). These happen via your preferred channel — Slack, WhatsApp, or equivalent. During high-risk rebuild phases this is especially important.

Weekly — three structured touches:

• Monday planning note — what is committed this week, expected outputs, any risks
• Midweek delivery — a visibly shipped artifact, decision, or retired risk
• Friday status note — Done / In Progress / Waiting on you / Next week

Monthly — retainer review: A short review covering outcomes delivered, rebuild risks retired, anything that slowed delivery, and whether the retainer should be maintained, expanded, or moved toward handoff.

6 - Decision points during the rebuild

As the engagement progresses, we repeatedly decide at the monthly review or earlier:

• What gets preserved versus replaced
• Whether to expand the rebuild scope or keep it narrow
• Whether to add launch / go-live support for a risky cutover window — priced separately, covers deployment support, rapid triage, and stakeholder communication
• When the rebuild goal has been reached and the engagement should close, continue as ongoing delivery, or hand off

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