01 · Recovery

Bring the project back on course.

Project lost momentum. The contractor's gone quiet. Budget draining without visible progress. Before you fire the team, rebuild from scratch, or write off the spend — a structured recovery with a clear plan for what comes next.

Discuss your project How it works

Why this works

I see the hidden risks in your IT projects and turn complexity into confident decisions — from the first idea to a working result.

Your result, the shared goal

My recommendations serve one thing — your result. People, decisions, and vendors are chosen to fit your project and its goals.

Technical depth

I understand architecture and read vendor proposals end to end — I see what's written between the lines.

Clarity upfront

Scope and price are agreed before we start, every decision in writing. You always understand what's happening and why.

02 Who this is for

Three typical situations I work with.

Each starts looking like a different problem but ends with the same need: someone reads the situation honestly and proposes a workable plan.

The contractor has gone quiet.

Calls get rescheduled. Updates come less often. The work chat where work used to happen has slowly gone silent. Maybe the team is overloaded; maybe your project lost priority; maybe a key developer left. Either way — response is slower than you need, and the spend keeps running. First job: honestly figure out whether the relationship can be repaired, or whether it should end cleanly.

Scope expands, outcome doesn't.

Started at $40K. Now at $80K with the original feature list still incomplete. Every change request lands with another "this will need two more weeks." You can't tell whether it's legitimate scope change or just stretching the project. First job: separate real scope changes from padding, renegotiate the agreement on transparent terms, restore progress against milestones.

The team is working but delivery has stopped.

People are engaged. Standups happen. Sprint reviews show movement. But the actual shipping has halted — and nobody inside the team can name why. First job: read the situation from outside the politics — process, scope, technical assumptions — and surface the real blocker without damaging the relationship.

03 How it works

What you get at each phase.

Work runs in phases. Each one ends with a concrete decision you can make based on real data.

01

Diagnostic (weeks 1-2).

Read the codebase, the contractor contract, the comms history; interview the team. Identify what's actually broken versus what's just symptomatic. End-of-phase artifact: a one-page recovery plan you can show co-founders, investors, or board.
02

Stabilize (weeks 3-8).

Either renegotiate the contractor agreement on transparent terms, or close it cleanly. Restore weekly delivery cadence. Triage technical debt — what we fix, what we live with, what we plan around. End-of-phase: predictable shipping resumed, financial bleed stopped.
03

Hand-off (week 8+).

One of two paths. Either the project is stable with the existing team and I step out, leaving documentation and a clear next step. Or we transition to a vetted team from the network with structured handover. Either way, the project runs without me in the room.

The end value isn't the plan itself — it's what the plan unlocks:

Restore delivery rhythm — predictable weekly progress you can show investors or team.
Stop financial losses on misaligned decisions — renegotiated terms, honest milestones, transparent spend.
Finish the project with a working outcome — either with you, or with a new team from the network.
Or make the honest call to stop — with minimal losses and a clear plan for what to do with existing code and data.

04 Not included

What recovery isn't.

→ Engineering management replacement. I read the project, align the plan, run process — but I'm not running developers day-to-day. If you need a fractional eng manager, that's a different format.
→ Hands-on code refactor. I don't rewrite production code. I tell you what needs rewriting, by whom, and in what priority.
→ "Just fire the contractor." Sometimes that's the answer. Often it's cheaper to renegotiate. An independent voice is needed exactly to call which path is actually realistic.
→ A guaranteed rescue at any cost. Some projects are better ended honestly than dragged on. That's part of the value too — and I'll say so directly if that's your situation.

05 Common questions

How is this different from hiring a new team?

A new team solves "who writes the code." Recovery solves "what actually needs doing, and why isn't the project moving." Often the first step reveals the team isn't the problem — scope, agreement, or process is. In that case a new team will just repeat the same situation 3 months later.

What if the project can't be recovered?

That's an honest answer, and I'll give it directly. Then work shifts to: cleanly closing current agreements with minimal losses; salvaging what's worth keeping (data, parts of the codebase, market learnings); and a plan for what to do with the remaining budget. Better to make that call in week 5 than spend another 4 months on something that won't fly.

How long before things stabilize?

First useful effect — end of phase 1 (week 2): you have a plan and an honest picture. Real delivery stabilization — phase 2 (weeks 3-8), depending on the depth of the problem. Deeply distressed projects take longer; an honest forecast comes after diagnostic.

Next step

A 30-minute conversation.

Discuss your project