From discovery call to working system: what to expect in the first 90 days

Most consulting proposals describe deliverables (a strategy document, an architecture diagram, a recommendations deck). They rarely describe the operational reality of working together — what gets scheduled, who owns what, what decisions need to be made when, what gets messy in week 6.

This is that operational reality, for a typical Baxter & Third engagement, from the day a prospect sends an inbound to the day a first operational increment goes live. We publish it because nothing about it should be a surprise — and because vagueness about process is usually a sign the firm doesn’t have one.

The shape below describes a typical 90-day Fix & Optimize or Design & Build engagement. Align & Scale advisory engagements have a different rhythm — quarterly cadence rather than daily — and are described separately in the services breakdown.

Days 0–7: discovery

Day 0 — the inbound

Someone fills the form on /contact or sends an email. Within one business day, you get a reply from one of the partners proposing a 30-minute call. We don’t book longer until we know what the call is about.

Days 2–4 — the discovery call

The 30-minute call is the real first interaction. It has three jobs:

1. Understand the situation enough to decide if we’re a fit. We ask about the operational problem, the systems involved, the people who’ll be affected, what’s been tried, and what success would look like in 90 days. We’re listening for: is this a problem we can solve, given our team and methodology?
2. Tell you honestly whether we’re the right firm. About a quarter of discovery calls end here, with a referral to someone better suited. That’s the system working as designed.
3. Agree on the next step. If we’re a fit, that’s a paid scoping engagement (1–2 weeks, ~₦2.5–5M) that produces the engagement proposal.

You walk away from the discovery call with three things: a clear sense of whether the conversation continues, a written summary from us within 24 hours, and either a scoping proposal or a referral.

Days 5–7 — scoping execution

If we’re moving forward, the next week is structured scoping. This isn’t yet the engagement — it’s the work of figuring out what the engagement should be.

Typical scoping activities:

• 3–5 deeper interviews with stakeholders we identified on the discovery call
• A walk-through of the current systems (read-only access, demo accounts, or shoulder-surfing)
• Sample data inspection: a sanitized export of relevant records, looked at jointly
• A workshop with the client team to align on success metrics
• A first-pass leak list (similar shape to the 30-day audit, compressed)

Scoping ends with a written engagement proposal: scope, team, duration, milestones, fee, what the client owns, what we own, what success looks like. Sign or don’t.

Days 8–30: foundation

Week 1 of engagement — kickoff and architecture spike

Once the proposal is signed:

• Day 1: kickoff meeting. Confirm roles, escalation paths, communication cadence (we default to a shared Slack channel + weekly written status). Sign the SOW. Provision us with the access we need (this often takes longer than it should — start it on day 1).
• Days 2–3: deep architecture work. We finalize the target system design, the data model, the integration boundary, the deployment topology. This is whiteboard work — output is a single architecture document the engineering team and the client’s tech lead both sign off on.
• Days 4–5: backlog construction. We translate the architecture into a 6–8 week implementation backlog with explicit sequencing and the assumptions behind each item. The backlog is shared in the same tool the client’s team uses (Linear, Jira, Notion) so visibility is automatic.

By end of week 1, the client should be able to look at a single document and answer: what are we building, in what order, with what assumptions, ending when?

Weeks 2–4 — first build increment

We default to 2-week sprints with a working demo at the end of each. The first sprint targets the highest-leverage piece of the system — usually one of:

• The data backbone (because everything depends on it)
• The authentication and authorization layer (because security retrofits are painful)
• The most-used user-facing workflow (because it builds client team confidence quickly)

By end of week 4, you should have:

• A running development environment with the foundational layer working
• Test data exercising the primary use case
• A demo the client team has tried and given feedback on
• An updated backlog reflecting what was learned

What usually goes wrong: the architecture assumption that worked on the whiteboard doesn’t survive contact with the real data. Adjustments happen here. That’s normal. The cost is small if you find it in week 3, large if you find it in week 12.

Days 31–60: operational fit

Weeks 5–6 — building toward the first user-visible workflow

By now the foundation is stable and we’re shipping features that actual users will touch. Typical work in this window:

• Building out the second and third workflows (the foundation enables them to go faster)
• Connecting to the first integration boundary (payment gateway, accounting system, existing CRM)
• Producing the initial admin/configuration tooling
• Setting up the staging environment that mirrors production

This is also where client involvement intensifies. The end users on the client side need to be available and engaged to validate workflows. If they’re not, the gap between “technically works” and “actually fits how we operate” never gets closed.

What usually goes wrong: a stakeholder who agreed to the workflow design in week 1 looks at the implementation in week 5 and says “actually, what we really do is…” — a process detail nobody surfaced before. We hold time for one of these per workflow. More than that means scoping was too thin.

Weeks 7–8 — pre-production work

This window is the unglamorous work that decides whether the go-live succeeds:

• Data migration trial runs — taking real (sanitized) data from the legacy systems into the new one. The first run always reveals data quality problems nobody knew about.
• Integration testing under realistic load — not just “does it work” but “does it work when 50 transactions hit it simultaneously.”
• Edge case validation — the cases the workflow walks through 1% of the time. These break implementations in production if they weren’t tested.
• Documentation drafting — runbooks, SOPs, admin guides. The team that operates the system should have everything they need to do so without us.

By day 60, the system is feature-complete for the scope agreed in week 1. The remaining 30 days are about making it operationally trustworthy.

Days 61–90: live, then embedded

Weeks 9–10 — UAT and pilot

User acceptance testing happens with real users, on staging, with real data, doing real tasks. We watch over their shoulders (literally — via screen share — when remote). The bugs they find are different from the ones we find. That’s exactly why this phase exists.

Around day 70, the client decides whether the system is ready to go live. We have a documented go-live checklist. The decision is the client’s — not ours — and there’s no penalty for saying “another two weeks.”

Weeks 11–12 — go-live and stabilization

The actual go-live is anticlimactic when phases 1–10 went well:

• A change-management window (often a weekend) when data cuts over and routing switches to the new system
• A pre-agreed monitoring period (typically 72 hours) when our team is on standby
• A rollback plan we hope we don’t need

The two weeks after go-live are about stabilizing operationally, not building. We:

• Sit with users daily for the first week, watching how they use it
• Capture and fix the friction that only appears in real use
• Update SOPs to reflect what real operation looks like vs. what we’d predicted
• Run a retrospective with the client team about what worked, what didn’t, what the next phase should address

Day 90 — embed

By day 90, the goal is that the client team owns the system completely. Our involvement at this point is limited to:

• Optional advisory retainer (light-touch monthly check-ins for ~6 months)
• On-call support for a contracted window (usually 90 days)
• A formal handover document with the runbook, architecture, decision log, and known gaps

About 60% of clients re-engage us within the next 18 months for the next phase. That’s a healthy ratio — it means the work was worth doing again, but not because the client became dependent. The other 40% don’t re-engage, which is also fine. The success metric we publish to ourselves is the day the client can operate the system without us.

What changes if the project is different

The shape above is the typical case. Variations:

• Pure advisory engagements (Align & Scale) skip the implementation weeks and substitute quarterly strategy work + monthly check-ins
• Larger platforms (multi-tenant SaaS like DevOS) run 6–9 months instead of 90 days, with the same shape stretched
• Regulated workloads (fintechs, parastatals) add a compliance review track in parallel — usually adding 2–4 weeks to the 90-day timeline. NDPC requirements shape the data architecture from week 1
• Recovery engagements (you’ve already tried with another firm and need it salvaged) skip the discovery phase and start with a stabilization sprint — different shape, different price

But the principles don’t change: scope tightly, ship in releasable increments, document everything, transfer ownership.

---

If you’re considering an engagement and want to understand what the first 90 days would look like for your specific situation — including which of the variations above applies — start a conversation. The discovery call is the actual first step, and you can decide whether to continue once you’ve had it. Nothing about our process should be opaque.