The Mid-Build Pickup - What the First 48 Hours Actually Look Like

Somewhere in every agency's history, there is a version of the same phone call. A project is live. Work is happening. But the PM is gone - left the company, moved to a different role, went silent - and someone has to step in immediately because the client has a call on Thursday.

That was the situation when I picked up Brieflex - an AI-powered California Bar Exam training platform built for law students preparing for one of the hardest professional exams in the United States. The product was real, the team was working, and the client, Elvis, had been patient. But behind the scenes there was no sprint plan, no time tracking, no SOW covering the work already in progress, and no structured way to tell the client what had been done, what was left, and when it would ship.

The instinct in that moment is to dive straight into the product - find out what is built, start making decisions, demonstrate momentum. That instinct is wrong. The product is not the problem. The operating system around the product is the problem. And if you fix momentum before you fix the operating system, you just move faster in the wrong direction.

The first 48 hours of a mid-build pickup are almost entirely about reading - not doing. Before you send a single message to the client, before you run a single standup, before you touch the backlog, you need to understand what is actually true about the project. Not what people think is true. What is actually true.

On Brieflex, that meant going through the existing SOWs line by line, mapping every feature against what was actually built versus what had been claimed, and calculating roughly how many hours had been spent across the two contracts. The number that came back was around 36 hours - spent without a time tracker, without documented proof, across work that was real but unverifiable if a client ever asked. That is a significant exposure for an agency.

What a good audit covers

• Scope reality check: Read every SOW and map each feature to its actual build state. Built, in progress, not started, or not applicable - four states only. No ambiguity.
• Hours audit: Find every hour spent and understand whether it is documented. If it is not, flag it before you do anything else. Undocumented hours are a liability, not a minor detail.
• Decision log: What decisions have been made verbally that were never written down? These are the scope landmines. A developer who remembers a call differently from a client is a dispute waiting to happen.
• Dependency map: What does the client own? What does a third party own? What are you waiting on? On Brieflex this included Stripe, Mailchimp integration, and a sign-up flow that was unscoped - meaning no estimate existed for it yet.
• Team health: Who is on this project? What are they working on right now? Do they know what they are supposed to be working on?

The audit is not pleasant. It will surface things that should have been caught earlier. That is the point. You cannot fix what you have not named.

Once the audit is done, the temptation shifts. Now you know what is broken - so the next instinct is to fix everything at once. Resist that too. A mid-build pickup requires a specific prioritisation: fix the operating system before you fix the product. The operating system is sprint cadence, time tracking, meeting structure, decision documentation, and scope contracts. The product is the code.

On Brieflex, I ran five moves in the first two weeks. In order:

• Hubstaff activated immediately: Every hour from the moment I stepped in was tracked. This was non-negotiable. An agency that cannot produce a time report on demand is an agency that will eventually lose a client dispute it should have won.
• Scope reprioritised with the client: I ran a priority alignment session with Elvis before I built any sprint plan. The order that came out - Custom Tutor Room first, then Stripe, then sign-up, with Mailchimp and analytics deferred - gave the team a clear, conflict-free delivery queue for the first time. Engineers should never have to guess what to build next.
• Sprint plan produced and committed: Four sprints, hard dates, defined scope per sprint. The sign-up feature was explicitly flagged as unscoped with a deadline for Elvis to provide requirements - because a sprint plan with a dependency that has not been sized is not a plan, it is a wish.
• Two SOWs produced: One covering the remaining scope already agreed, one covering the new scope. Both priced, both with payment schedules. No more uncovered work in flight.
• Meeting structure locked: Elvis had actually asked for structured agendas on a previous call - completed tickets, in progress, what is coming. I committed to that format from the next meeting and delivered it. It sounds basic. It had not been happening.

None of this touched the product. All of it changed the project.

Here is the part that is genuinely hard: the client has usually been through something uncomfortable before you arrived. Maybe deliveries were late. Maybe updates were inconsistent. Maybe they have been generous with patience that was close to running out. The first client conversation after a pickup has to do two things simultaneously - acknowledge the gap without throwing the previous team under the bus, and demonstrate immediately that things have changed.

The way to do that is not through words. It is through structure. Show up to the first call with a written agenda. Send a post-meeting summary the same day. Have a sprint plan ready to walk through. Every one of those things signals, without saying it out loud, that there is now a process in place and they can trust it.

On Brieflex, I also had to handle a stakeholder triangle - Elvis on product decisions, Dan as an investor stakeholder on commercial decisions, and the BetaCraft team on delivery. Dan had to sign off on certain scope items before we could commit hours. I made that dependency explicit, in writing, with a named deadline. Not "we should probably align on Mailchimp" - but "Mailchimp is blocked on Dan's written confirmation, required by April 14, or it moves to a later SOW." Vague dependencies become scope disputes. Named dependencies become calendar items.

Two weeks in, the project looks different - not because the product has changed, but because the team has a structure to work inside. There is a sprint cadence. Decisions are logged. Hours are tracked. The client knows what to expect and when to expect it. The developers know what they are building and in what order.

What also changes is how you manage the product itself. With the operating system stable, you can start to actually look at what was built and make informed judgements about it. On Brieflex, this meant reading Vasanta's backend design for the Tutor Room and being able to tell Elvis it was solid - not because I was translating from the developer, but because I could read it. It meant understanding why the Drill Room question pre-loading performs differently for IRAC versus rule statement question types, and asking the right diagnostic question rather than accepting "it is just slower" as an answer.

That is the part of the job that requires the engineering background. You can run a great mid-build pickup without it - the audit, the sprint plan, the SOWs, the meeting structure, all of that is process. But the ability to read the architecture, challenge an estimate, or catch a technical decision that will cause problems later - that requires having been on the other side of the table.

Every mid-build pickup I have done has taught me the same thing in a different way. The project is not broken. The operating system around the project is broken. The code is there. The team is there. The client relationship is usually still salvageable. What is missing is structure - and structure is exactly what a Technical PM is there to provide.

The temptation to demonstrate competence by touching the product immediately is a trap. The client does not feel better because you changed a ticket status. They feel better because the next meeting has an agenda, the update arrives on time, and the sprint plan answers the question they have been trying to ask for three weeks: when is this actually going to ship?

Answer that question with a plan that holds, and the rest follows.