Advisory · Labs Brief us →
● METHODOLOGY DOCUMENT 007 PRACTICE: METHODOLOGY
// METHODOLOGY · PROCESS

How the work actually happens.

Most consultants describe their process in three-bullet abstractions. This is the concrete version — the four stages an engagement runs through, with the discipline and the receipts that make each stage real.

// THE FOUR STAGES · AT A GLANCE

Each stage is a real "no" point.

Neither side has to continue past any stage boundary. The shape of the work below is the contract — we walk through the prose version of each stage in the document that follows.

  1. // 01

    Discovery

    1 HR · NO COST

    A 1-hour working session preceded by a written brief. We arrive with hypotheses about where the cost lives and come out with a scope contract that names what is in and what is not. Roughly 1 in 3 conversations end with us recommending against working together — that's by design.

    Deliverable
    A written scope contract — what the Audit will cover, what it will not, and what a successful deliverable looks like.
  2. // 02

    Investigation (Audit)

    2 WEEKS · $2,500

    A structured deep dive: funnel instrumentation against your data, full stack audit, and migration archaeology across 1,397+ production migrations of accumulated pattern knowledge. We read the migrations the way other engineers read commit messages — the only honest record of how a database actually evolved.

    Deliverable
    A prioritized findings document with ROI ranges + a scoped Project quote. Converts to a Project or Retainer at a discount.
  3. // 03

    Project cycle (Build)

    2–3 WK CYCLES · FROM $15K

    Fixed-scope shipping under a 4-part discipline stack: the /go workflow (pre-implementation alignment), 92% test coverage enforced via pre-push hooks, a seven-specialist pre-merge review pipeline, and explicit AI-discernment calls on every feature. Every commit deploys to staging; nothing lands in a sandbox to 'prove the concept.'

    Deliverable
    Production code deployed to your stack. Migration safety gates, monitoring, CI/CD. Pattern library + lessons retros committed in your repo from day one.
  4. // 04

    Production handoff

    ONGOING · BUILT IN PARALLEL

    Not a transition event — a continuous output of the Build phase. Markdown runbook written for the engineer who has never seen the system, .claude/patterns/ library documenting reusable patterns as they were discovered, .claude/lessons/ retros named after the actual bug. All committed to your repo as deliverables, not internal notes.

    Deliverable
    A team that can take over the system within 72 hours. That's the test we apply: could a new engineer be on-call for this in 72 hours? If not, the handoff isn't done.
// 01 · DISCOVERY

How does Advisory Labs start an engagement?

Every engagement starts with a written brief and a 30–60 minute working session before any billable work begins. The objective is to find the single highest-cost constraint in the operator's funnel. Roughly one in three conversations end with us recommending against working together. Nothing is billed at this stage by design — the call itself is the diagnostic.

Discovery costs nothing because the conversation itself is the diagnostic. We ask operators to send a written brief before the call — not a polished RFP, just an honest account of where the funnel breaks, what the stack looks like, and what they've already tried. We read that brief, form hypotheses, and show up to the 30–60 minute session with a prioritized list of questions rather than a slide deck.

The call has one objective: find the single highest-cost constraint in the operator's funnel. In practice, that means walking through the anatomy of their lead flow from source to close — how leads come in, how they're qualified, how they're routed, what the CRM state looks like, where the first silent failure lives. Most operators have already formed opinions about their top-three problems. We take those seriously. We also look for the one they haven't named yet, because in a complex stack it's almost always there.

If we can find the constraint in 60 minutes, we say so and describe what addressing it would require. If we cannot, we say that too.① The session ends with a shared understanding of scope — what is in, what is not, and what the investigation phase will confirm or revise. Nothing is billed at this stage.

  1. // 1.1

    Written brief intake (24–48 hr reply window)

    We read every brief before we respond. The reply either names a time to talk or explains why the fit isn't right. No auto-responder, no calendar link that books before we've read anything.

  2. // 1.2

    30–60 minute working session (funnel anatomy + stack inventory)

    We ask about lead sources, qualification logic, CRM state, voice intake, enrichment, sequences, and where conversions visibly drop. We surface the top-three drop-off points the operator already suspects and test whether our hypotheses match theirs.

  3. // 1.3

    Scope contract (written before any work begins)

    A short written document — not a legal contract, but a mutual record — naming what the investigation will cover, what it will not, and what a successful audit deliverable looks like. This is the first real "no" point: either side can walk away cleanly.

// 02 · INVESTIGATION

What does the two-week investigation phase actually produce?

Two weeks of structured deep-dive across funnel instrumentation, full stack audit, and migration archaeology — concluding in a prioritized findings document with ROI ranges and fixed-price options for the Build phase. Across the portfolio we have read through 1,397+ production migrations. The deliverable is what to build first, in order, with numbers behind the order.

The investigation phase is two weeks of structured work that produces one deliverable: a prioritized findings document with ROI ranges, not a generic capability assessment. Before we write a line of code, we need to understand what the system actually does versus what it's supposed to do — and those two things are rarely the same.

The first thing we read is the migrations folder.② Every Supabase project we've worked with has migrations that tell a story the README doesn't — columns added and then removed, tables that were renamed three times, index strategies that changed as query patterns shifted. Across the portfolio we've read through 1,397+ production migrations. That volume means we recognize the patterns: where a schema drifted from its original design, where a hotfix introduced a constraint that now blocks a feature, where a NULL-able column is doing work that belongs in a separate table.

Stack audits cover the full surface: languages and frameworks, vendor integrations (CRM, dialer, SMS/email, enrichment), where authentication and authorization live, what the observability setup looks like, and which of the integrations are running without error handling. Most real-estate stacks we audit have at least one silent failure path — a webhook that drops payloads without logging, a sequence enrollment that fails open and fires again, an enrichment call that returns a partial result and writes it as complete. We document all of them.

  1. // 2.1

    Funnel instrumentation (run against your data)

    We map conversion rates at each handoff point in the funnel — source to lead, lead to qualified, qualified to contacted, contacted to appointment, appointment to close. Numbers that operators estimate frequently differ from what the database records show. We use the database.

  2. // 2.2

    Stack audit (languages, frameworks, vendors, drift surfaces)

    Full inventory of the technical stack, with a specific focus on where silent failures live: unhandled webhook payloads, enrichment calls that return partial data, sequence enrollments that fire on error rather than failing closed.

  3. // 2.3

    Migration archaeology (the honest record)

    We read the full migrations history to reconstruct the real schema evolution — what was added, removed, renamed, and why the current shape differs from the design doc, if one exists. This surfaces constraint conflicts and orphaned columns before they become production incidents.

  4. // 2.4

    Findings document (prioritized backlog with ROI ranges)

    The audit deliverable is a written document that names what to build first, what to skip, and why — with rough ROI ranges for each recommendation. It also includes fixed-price options for the build phase, scoped from the findings. This is the second "no" point: the operator can take the findings document and build with someone else.

// 03 · BUILD CADENCE

What discipline does Advisory Labs run during a Build phase?

Six to eight weeks of weekly shipping under a four-part discipline stack: the /go pre-implementation alignment workflow, TDD with 92% coverage enforcement, a seven-specialist pre-merge review pipeline (architecture, data model, AI-correctness, security, performance, observability, rollback), and explicit AI-discernment decisions on every feature. Every commit deploys to staging; nothing lands in a sandbox to prove the concept.

The build phase is six to eight weeks of weekly shipping under a discipline stack that most consultants do not run. It starts before any feature work begins: the /go workflow requires a written pre-implementation plan — problem statement, proposed approach, risks, test strategy — reviewed and approved before any code is written. This single gate eliminates the most common failure mode in AI feature development: building the right thing in the wrong way because the implementation question was never asked out loud.

Every PR goes through a seven-specialist review pipeline before merge: architecture, data model, AI-correctness, security, performance, observability, and rollback. Each specialist is a focused review pass with a structured checklist. The pipeline catches what unit tests cannot — a cache-invalidation strategy that works in development but breaks under concurrent writes, a prompt that produces correct outputs on the happy path but hallucinates on the edge cases, a migration that runs cleanly on a staging database but locks a production table for 40 seconds at peak traffic. Real catches in the last year include a stale eligibility cache, doubled token spend from a leftover debug instruction, unescaped property addresses enabling prompt injection, and a dev-only migration that would have locked production for 90 seconds.

Test discipline runs at 92% coverage on production codebases, enforced by pre-push hooks. Migration safety gates block any deploy that includes an unapplied migration against the target environment. Sentry is wired in from day one — not added at the end. The principle is that production-first is not a phase you enter; it is the default operating mode from the first commit.

A frequently misunderstood part of the methodology is where we choose not to use AI. A real-estate GTM intelligence engine we shipped uses deterministic rules and math for lead scoring — four scoring models, nine enrollment motions, zero LLM calls in the critical path. The reasoning is straightforward: a score that can be explained to a sales manager, backtested against historical data, and iterated in TypeScript without re-prompting is worth more than a score that's slightly more accurate but opaque. The same logic applies to eligibility engines — five distinct underwriting calculators across the portfolio all run on deterministic rules read from admin-controlled configuration, not on model inference. The discernment call — when to use Claude, when to use Haiku for structured evaluation, and when to use rules and math — is made explicitly on every feature.

For AI features that do use models, the implementation follows specific patterns: agentic web-search enrichment with strict anti-fabrication rules and confidence labeling per field; transcript QA scoring via Claude Haiku that returns structured JSON with turn-by-turn observations and feeds back into prompt edits; voice agent prompt versioning with drift detection against deployed agent state.③ These are not general AI integrations — they are production systems with defined failure modes, rollback paths, and observability.

  1. // 3.1

    /go workflow (pre-implementation alignment)

    Every non-trivial change starts with a written plan: problem statement, proposed approach, risks, test strategy. Plan reviewed and confirmed before any code is written. Eliminates the most common build-phase failure mode — right problem, wrong implementation — before it consumes engineering time.

  2. // 3.2

    TDD with 92% coverage enforcement

    Tests are written before implementation on every feature. Coverage gates run at pre-push via hook. Migration safety gates block any deploy carrying an unapplied migration against the target environment. Sentry error tracking from commit one.

  3. // 3.3

    Seven-specialist pre-merge review pipeline

    Architecture, data model, AI-correctness, security, performance, observability, rollback — seven structured review passes on every PR. Each pass has a checklist. Catches what unit tests cannot: cache-invalidation under concurrent writes, prompt-injection vectors, migrations that lock production tables, token-cost regressions.

  4. // 3.4

    Weekly cadence (Monday plan, daily ship, Friday demo + retro)

    Monday sets the week's scope in writing. Work ships daily to staging. Friday demo is a working walkthrough of what shipped — not a status update. Retro captures what changed in the .claude/lessons/ file for that week if anything notable happened. Async-first communication; documentation-heavy.

  5. // 3.5

    AI discernment (when to use models, when to use math)

    Explicit decision on every feature: Claude for web-search enrichment and structured evaluation, Haiku for transcript QA and lightweight classification, deterministic rules for scoring and eligibility. The decision is documented in the implementation plan, not made by default.

// 04 · PRODUCTION HANDOFF

What gets handed off when an engagement ends?

A Markdown runbook written for the engineer taking over the system who has never seen it, a .claude/patterns/ directory of reusable patterns documented as they were discovered, and a .claude/lessons/ directory of incident retros named after the actual bug — all committed in the operator's repository from day one. The test we apply: could a new engineer be on-call for this in 72 hours? If not, the handoff is not done.

The handoff is not a transition event — it is a continuous output of the build phase. The runbook, the pattern library, and the lessons log are built in real time as the engagement progresses, so by the time the build phase ends they are already in use by the team, not handed over cold.④

The Markdown runbook lives in the repository root. It is written for the engineer who will take over the system and has never seen it before. The first section walks through the first 90 minutes of ownership — how to set up local environment, where the edge functions live, how to read the Sentry error stream, what the most common failure modes look like and how to resolve them. We've seen senior engineers join a 100k-user platform and ship their first production PR by end of week one because the runbook anticipated their first three questions.

The .claude/patterns/ directory contains reusable patterns documented as they were discovered during the engagement — things like the lead deduplication strategy, the CRM panel architecture, the sequence enrollment failure-close pattern. Each pattern file names the problem, the solution, and the constraint that makes the solution the right one in this context. The .claude/lessons/ directory contains incident retrospectives, named after the actual bug. When a migration drift caused an outage, the lesson is in a file called something like migration-drift-outage-2026.md — not "Incident #4."

  1. // 4.1

    Markdown runbook (first-90-minutes format)

    Written to answer the first three questions an incoming engineer asks. Covers local setup, production topology, Sentry configuration, common failure modes with resolution steps, and the deployment process. Lives in the repository root. Updated throughout the engagement, not written at the end.

  2. // 4.2

    .claude/patterns/ — reusable pattern library

    One Markdown file per pattern, documenting the problem, the solution, and the constraint. Patterns are extracted from the build phase in real time. They ship in your repository, not ours, and remain useful to the team after the engagement ends.

  3. // 4.3

    .claude/lessons/ — incident retros named after the bug

    Every production incident during the build phase gets a lessons file. Named after the actual bug, not a ticket number. This makes lessons searchable by the scenario that caused them — which is how engineers look for them under pressure.

  4. // 4.4

    On-call transition (clean hand-off, no dependencies)

    When a build completes or a retainer ends, the architecture, the observability, and the documentation are in a state where an incoming engineer can own the system without a handoff call. That is the test we apply: could someone new be on-call for this in 72 hours? If not, the handoff isn't done.

// FAQ
How long does a typical engagement take?
The discovery session is free and takes 1 hour. The Audit runs two weeks at a fixed fee of $2,500 — stack audit, prioritized roadmap, scoped follow-on Project quote. The Project phase runs in 2–3 week shipping cycles at fixed scope and price, starting at $15,000. Retainer engagements run a six-month minimum at $7,500–$15,000 per month. Each stage is a genuine decision point — neither side has to continue. See the Services page for the full motion.
Do you write the code or oversee other engineers?
We write the code. "Fractional" does not mean "manager-of-juniors." Every commit, every migration, every deploy comes from us directly. That is what makes the pattern library and runbook credible — they were written by the engineer who built the system, not summarized from someone else's PR.
What happens to the code and patterns after handoff?
Everything ships in your repository. The .claude/patterns/ library, the .claude/lessons/ incident retros, and the Markdown runbook all live in your repo from day one — not in ours. When the engagement ends, your team owns the system fully. There is no vendor lock-in, no proprietary toolchain, and no call-us-first dependency baked into the architecture.
When would Advisory Labs turn down an engagement?
Roughly one in three strategy session conversations end with us recommending against working together. The most common reason: the operator's core constraint is sales process, pricing, or product-market fit — not AI infrastructure. We will not start an engagement we cannot ship value on, because the only durable referral source we have is operators who got real outcomes. Other disqualifiers: timelines under three months, scope that requires us to displace a working in-house engineer, or compliance requirements outside our US-only remit.
What does the first week of a Project cycle look like in practice?
Week one is repo onboarding, environment setup, and shipping the first non-trivial migration to staging. We commit the .claude/patterns/ skeleton, the runbook, and the seven-specialist review configuration on day one — those are deliverables, not internal tooling. By Friday of week one there is at least one merged PR that closes a real ticket from the audit, deployed to staging. We do not run a "ramp-up week" because the audit phase already did the discovery.
How is this different from hiring a senior AI engineer or another consultancy?
Versus a senior AI engineer hire: same shipping pattern at one-third the cost basis, no six-month hiring cycle, no equity carve-out, six-month minimum versus open-ended employment. Versus a consultancy: we write the code rather than producing slides; engagements run two to three week fixed-price Project cycles rather than open-ended hourly billing; the pattern library and runbook ship in your repo, not in a deliverable PDF. We are the engineer you call when the consultant's pilot stalled.
Do we keep our existing CRM, LOS, or dialer — or do you replace them?
We do not replace systems of record. Encompass, LendingPad, Salesforce, HubSpot, Lofty, BoomTown, Five9 — we wire intake, enrichment, and decision logic around them, not on top of them. The orchestration layer talks to your existing systems through their APIs. The only replacements we have done in production are CRM consolidations where the operator was already running three or more overlapping tools and asked for a single screen — and even then, the underlying systems of record stayed.
How do you handle on-call coverage during the engagement and after?
During the engagement, we carry on-call for anything we shipped — escalation routes through PagerDuty or your incident channel directly to us, with response targets matching the severity. After the engagement, on-call transitions to your team. The test we apply at handoff: could an incoming engineer be on-call for this system within 72 hours of starting? If the answer is no, the runbook is not done. We do not sell ongoing on-call as a managed service.

Brief us.

If this reads like your operating model, send a brief. We reply within two business days.

Send a brief →