Methodology

How I run an engagement

Four phases, 10–14 weeks, fixed fee. Built like an engineer would build it: instrumented, evaluated, and owned by your team on day one.

Operating principles

These aren't marketing lines. They shape every decision inside the engagement.

Outcomes over outputs

The deliverable isn't a deck or a Notion page. It's measurable adoption and a velocity number that moves. We agree on the metric in week one and instrument for it.

Vendor-agnostic by design

Claude Code, Codex, Cursor, Copilot, Windsurf are tactical. The platform layer is strategic. I build to the meta-layer so the system survives the next tool launch.

Evaluations are the missing layer

Most rollouts skip evals because they're hard. That's why adoption stalls. Codebase-specific evaluation harnesses are non-negotiable in every engagement I run.

Your codebase is the context

Generic agents are weak. The moat is org-specific context: internal MCP servers, packaged skills, and subagent patterns shaped to how your teams actually ship.

The four phases

Each phase has a clear scope, deliverables, and exit criteria. Phases overlap where the work calls for it. Engineering, not theater.

Discover

2–3 weeks

I start by understanding what you actually have: telemetry, interviews, and a frank assessment of where the platform isn't yet built.

Tool usage telemetry

Which seats are active, which tools touch real codebases, where the drop-off happens between license and daily use.

Developer interviews

10–15 conversations across teams. Where are people working around the AI? Where would they pay for better tooling?

Security & compliance review

Audit logging, secrets handling, data residency, model approval policies. What's in place, what needs to be.

Platform readiness assessment

Monorepo vs. polyrepo realities, CI/CD shape, existing internal tooling, the org's appetite for shared infrastructure.

Phase output

Written platform blueprint, prioritized roadmap, and a metrics plan you can defend to leadership.

Standardize

Weeks 3–8

I build the shared platform layer that turns scattered tool licenses into a developer platform.

Standardized configurations

Settings, hooks, permission policies, and safety guardrails packaged as version-controlled defaults. Applied across tools, not per-developer.

Skill libraries

Org-specific skills packaged for reuse: deployment runbooks, codebase navigation, code review patterns, incident response, internal API recipes.

Internal MCP servers

Shared context servers exposing codebase docs, runbooks, observability data, and internal API specs to every agent in the org.

Subagent and orchestration patterns

Composition patterns tuned to your topology: monorepo, microservices, frontend/backend splits, monolith carve-outs.

Phase output

A working platform deployed to real teams. Configs, skills, and MCP servers checked into your infrastructure, not mine.

Instrument

Runs alongside phase 2

Nothing ships without evaluations. This is what separates a platform from a license bill.

Codebase-specific eval harnesses

Regression tests for agents against your real code, your real PRs, your real bugs. Run on every config change.

Ship/no-ship quality gates

Automated signals that tell the platform team when an upgrade is safe to roll forward, and when to hold.

Adoption telemetry

Usage by team, by tool, by task type. Where is the platform working? Where is friction killing adoption?

Cost & quality dashboards

Token spend, eval pass rates, time-to-merge, PR throughput. The numbers leadership actually wants to see.

Phase output

Dashboards and gates your team operates. Decisions become data-driven, not vibes-driven.

Enable

Weeks 8–12

A platform nobody uses is sunk cost. Adoption is part of the deliverable, never a hopeful side effect.

Team onboarding

One-day workshop per team, recorded for replay. Hands-on patterns, not demos.

Internal champions

2–3 senior engineers trained as platform owners. They leave the engagement able to extend it without me.

Operating runbooks

Documented procedures for model upgrades, new tool integration, eval maintenance, and quarterly adoption reviews.

Executive briefing

A clean readout for leadership: what shipped, what moved, what comes next, and the case for the retainer if it makes sense.

Phase output

Your team owns the platform. I'm available on retainer if you want it, but the engagement stands on its own.

What's different

A few things that show up in every engagement and are easy to miss when comparing on a website.

Hands on keyboard

I write the configs, ship the MCP servers, and run the evals. No subcontractors, no junior associates billing my rate.

Single senior point of contact

You work directly with me from discovery through enablement. No account team layer, no handoffs between phases.

Production codebases, not pilots

The work lands in your real repos with real teams. Pilots that never ship don't move metrics.

Want this for your team?

The services page covers scope, pricing, and how to start.

See the offer Read the blog