Scope creep
The single most common Build failure is agreeing to 'one more small thing' every week. Phase 2 Architect exists to freeze scope; Phase 3 Build exists to execute it.

III.Flame
03 · Spark · Four to eight weeks
Four to eight weeks of production work.
Build is the longest phase of the Phoenix Methodology and the one most founders think is the whole engagement. It isn't. It's the production run against the architecture drawn in Phase 2 — systems, automation spine, SI surfaces, data flows, permissions, and human handoffs — shipped incrementally so you see something live every week.
Four to eight weeks of careful, sequenced, integration-first construction. We build the software setup, the automation workflows, the SI surfaces, the data flows, and the human handoffs specified in Phase 2 — in a deliberate order, tested against real inputs, with weekly checkpoints where working functionality ships to you.
Build is deliberately not:
You leave with
Functioning systems with real data; automation workflows running against real inbound; SI surfaces deployed with human-in-the-loop checkpoints; documented permissions and handoffs; a weekly change-log showing exactly what shipped each week. At end of Build, your team is using the system for real work.
Build runs in a specific order, derived from dependency. Data migration first, because every downstream workflow depends on clean data. systems and pipelines second, because the software is the system of record. Integration spine third, so tools can talk. Automation workflows fourth, starting with the lowest-risk triage work and moving toward sensitive outputs. SI surfaces last, layered onto working automation — never the other way around.
If a consultant starts Build with 'Let's stand up the SI chatbot,' stop the engagement. They've sequenced backwards.
Every week of Build, something runs in production. If we reach week four and nothing is live, we've lost the plot and we'll say so before you have to ask. The weekly-ship rule is the single strongest discipline we impose on ourselves.
Weeks one and two: your team continues operating the legacy system unchanged. Weeks three and four: your team begins shadowing the new system alongside the legacy one. Weeks five through eight: your team is running the new system live, with the legacy system as a fallback. By the end of Build, the legacy system is decommissioned.
Where it fails
The single most common Build failure is agreeing to 'one more small thing' every week. Phase 2 Architect exists to freeze scope; Phase 3 Build exists to execute it.
If the consultant is disappearing for three weeks at a time and reappearing with a 'progress update,' the engagement is in trouble. Demand live weekly demos against real data.
Build that doesn't include your operators in weeks three through eight hands over a system nobody knows how to run. Amplify exists specifically to prevent this — but it starts in Build.
Four to eight weeks depending on the complexity of integrations and the number of workflows in scope. A single-workflow Build runs four weeks; a full systems + automation + SI surface Build runs eight.
Both. Phase 2 Architect decides which tools stay and which get replaced. Build executes that decision. Roughly half our Builds retain the tools you already use; roughly half migrate to custom software.
The weekly-ship discipline means every week has a committed, tested deliverable. If something breaks, it's caught in the weekly demo, not a month later. We do not wait for end-of-Build to surface issues.
If Phase 2 is done (ours or someone else's) and you need production build work, we can engage specifically on Build. Weekly ship. Weekly demos. No surprise rebuilds.
Nicholas runs this studio on it. Mobile speed went from 49 to 92. We run on it too.