Advisory · Labs Brief us →
● METHODOLOGY DOCUMENT 007 FIELD: APPLIED AI 05/19/2026
// 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.

// 01 · DISCOVERY

Read the brief. Get on the call. Find the constraint.

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

Instrument the funnel. Audit the stack. Write the plan.

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

Weekly shipping. TDD discipline. Pre-merge review pipeline.

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

Runbook. Pattern library. On-call coverage.

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 30–60 minutes. The investigation (Audit) runs two weeks at a fixed fee starting at $5,000. The build phase runs six to eight weeks at fixed scope and price, starting at $25,000. Retainer engagements run a six-month minimum at $7,500 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.

Brief us.

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

Send a brief →