A strategy memo for enterprise SaaS leadership

Own the seam. Rent the intelligence. Ship faster than anyone still building a platform.

The case for running product delivery on Claude-native tools, a proprietary MCP layer, and Asana as the canonical spine — rather than building another in-house platform in the age of generative AI.

ContextEnterprise SaaS serving Fortune 500 clients
HorizonShip now, compound over 36 months
AudienceCXO, VP Engineering, Head of Product
01 · The core argument

Fifteen years ago, we told manufacturers not to build software. Now SaaS leaders are building everything in-house.

The logic that built the SaaS industry — buy the commodity, own your differentiation — has been abandoned by the same leaders who sold it. Generative AI has not changed the principle. It has sharpened it.

The thesis
Don't build an in-house product development platform on top of foundation model APIs. Use Claude-native tools for execution, an in-house MCP layer for what is genuinely yours, and canonical SaaS systems for the work graph. The result is 80% of the value at 20% of the cost, and it ships in weeks rather than years.
Option A — in-house PDLC platform
Branded UI on foundation APIs, internal agent orchestration, custom ticket module
  • Capital cost 15–25 engineers for 18 months to reach parity with commodity tools that already exist.
  • Perpetual parity gap Every Claude release creates a new feature your team must replicate or wrap. The gap widens every quarter.
  • Opportunity cost Headcount spent on internal infrastructure is not spent on product roadmap, client delivery, or differentiation.
  • Vendor risk unchanged You still depend on foundation model APIs underneath. You have added a maintenance burden without removing the dependency.
  • Justified only if The platform itself becomes a product you sell. Otherwise the math does not close at any scale below $500M ARR.
Option B — Claude-native plus MCP seam
Claude Code, chat, and Cowork for execution · proprietary MCP for codebase and context · Asana as the spine
  • Compounding capability Every Claude release — longer context, better agents, new tools — lands in the stack automatically.
  • Thin seam, real moat The codebase MCP encodes your conventions and architecture. This is what generic tools cannot replicate.
  • Canonical systems for commodity layers Asana for work, Drive for knowledge, Gmail and Slack for signal. Each proven at scale, each native to your team.
  • Optionality preserved MCP is the swap point. A better model, a different provider, a new tool — all are configuration changes, not rewrites.
  • Graceful decay If foundation models absorb the MCP layer in two years, the investment has already paid off and migration is clean.
Honest counterarguments — and why they fail at enterprise scale

The strongest case for Option A is codebase depth and compliance control. For FieldAssist-scale companies that have already built a proprietary codebase MCP, this argument collapses — the depth is already owned, and compliance is owned at the MCP layer rather than the UI layer. The second argument is vendor lock-in with Claude. Real, but manageable — model routing through MCP gives you a swap path, and the lock-in is shallower than the migration cost of leaving a built platform. The third is branded client experience. Valid only if you sell the platform; otherwise, clients care about delivery speed and output quality, neither of which improves with a custom UI.

Net verdict — Option B wins on every dimension that compounds, and ties or loses only on dimensions that are fixed-cost. The gap widens with every Claude release.

02 · Architecture

Four layers. Each does one job. Nothing overlaps.

The discipline that makes this work is refusing to let layers bleed into each other. Execution runs in Claude. Work runs in Asana. Knowledge lives in Drive. Differentiation lives in your MCP.

Execution
Claude chat Claude Code Claude Cowork Claude artifacts
Native Claude surfaces handle synthesis, code generation, design, and content drafting. Rented, not built. Every capability improvement lands here automatically.
Seam
Codebase MCP Drive taxonomy MCP Asana MCP Model routing
The thin proprietary layer that encodes what is genuinely yours — codebase conventions, knowledge taxonomy, workflow graph. Owned by the platform lead. Swappable at the model boundary.
Systems
Asana — work graph Drive — knowledge Gmail · Slack — signal GitHub — code
Canonical systems of record. Each does one job industrially well. Asana owns every ticket, every gate, every owner. If it is not in Asana, it does not exist.
Governance
Workflow · VP Eng Evals · Staff Eng MCP · Platform lead Cadence · Delivery lead
Four named functions, four named humans. No committees. No overlap. This is where accountability lives — and it is the single discipline that separates a working system from an undocumented mess.
03 · The workflow

From client request to production deploy — humans decide, agents execute, automation moves tickets.

Every step below is one of three things. The discipline is that it stays one thing. Humans never draft what agents can draft. Agents never approve what humans must approve. Automation never decides anything.

Human decision
Agent invocation
Background automation
01
CS captures the request
Customer success invokes the intake skill with raw client input. Claude drafts a structured ticket using client history from MCP. CS reviews, edits, submits to Asana.
Human + Agent
02
CS lead triages and graduates
Daily review of the intake board. Approval is the graduation. Asana rule fires a webhook and creates the corresponding ticket in the Product Delivery project.
Auto on approval
03
Product drafts the spec
PM invokes spec.draft and design.mock. Claude reads Drive, architecture docs, and prior specs via MCP. Spec and mocks saved to Drive, linked in Asana.
Agent
04
PM approves for build
Second human gate. The spec either graduates to engineering or returns to the PM for iteration. Approval is a single click in Asana.
Human
05
Engineer picks up the ticket
Engineering lane shows a new ready-for-dev ticket. Eng lead assigns in standup, or engineer self-assigns. They open Claude Code and invoke code.scaffold.
Human
06
Claude Code builds against the codebase MCP
Reads repo conventions, generates the branch, implements, writes tests, opens a PR. For well-scoped tickets, this can run headless — assigned to the agent, returns a PR autonomously.
Agent
07
Evals run automatically on PR open
GitHub Action invokes eval.run. Results post back to the Asana ticket as a comment. Regression flags block graduation until resolved.
Auto on PR
08
Eng lead reviews the PR
Third human gate. Code review, eval check, merge decision. No code ships without named engineering approval. Merge triggers staging deploy and ticket graduation.
Human
09
Delivery drafts UAT pack and release notes
Delivery lead invokes uat.brief and release.notes. Claude generates a client-facing UAT document from spec and PR. Sent to client.
Agent
10
Client signs off — production deploys
Fourth human gate. Signoff marked in Asana triggers production deploy. Ticket auto-closes. Decision log pushed to Drive. Learnings feed the next cycle via retro.synthesize.
Human + Auto
04 · The automation layer

Ten webhooks and six skills keep the pipeline moving when no one is at their laptop.

Interactive work happens on laptops. Autonomous work runs on a Cloudflare Worker. Build both from day one — the second is what makes the system continue working while the team is asleep.

Ticket graduation between projects
Status change in Asana fires a webhook. Worker creates the next-stage ticket, populates fields, links the parent. Human approval remains the trigger; movement is mechanical.
Asana webhook
Headless agent run on assignment
Ticket assigned to the agent user fires a webhook. Worker clones the repo in a sandbox, invokes Claude Code headless with the spec as context, opens the PR, posts back to Asana.
Asana assignment
Eval suite on pull request
PR opened triggers GitHub Action. Runs the eval suite against the change. Posts results as a comment on both the PR and the Asana ticket. Blocks merge on regression.
GitHub PR open
Staging deploy on merge
PR merge triggers CI/CD to staging. Asana ticket graduates to the Delivery project with deploy link and commit SHA attached automatically.
GitHub merge
Client signoff to production
Signoff custom field marked yes in Asana triggers production deploy pipeline. Release notes auto-post to client. Slack notification to delivery lead.
Asana field change
Scheduled retro synthesis
Cron at sprint end invokes retro.synthesize on closed tickets. Produces a structured summary. Posts to Slack channel and Drive as a sprint retrospective document.
Schedule — weekly
Slack digest for daily standup
Morning cron reads Asana boards via MCP. Posts a per-team digest to Slack — what moved, what is stuck, what needs attention. Replaces manual standup prep.
Schedule — daily
Client requirement ingestion from Gmail
Labelled Gmail thread fires a webhook. Worker invokes requirement.synthesize with the thread as context. Drafts a structured intake ticket for CS to review and submit.
Gmail label
05 · Evolution

Ship now. Compound over 36 months. Absorb what foundation models make free.

The architecture is designed for graceful evolution. Start thin, prove the pattern, expand the envelope. Every capability that foundation models absorb over time thins your seam further — which is the goal, not a risk.

Phase 1 · 0–6 months
Establish the spine
Ship immediately
  • Four Asana projects configured with graduation rules.
  • Codebase MCP exposed to Claude Code across the team.
  • Six core skills in the library, owned by the platform lead.
  • Cloudflare Worker running the first five webhook automations.
  • Four governance owners named and operating.
Phase 2 · 6–18 months
Expand the envelope
Prove autonomy on real work
  • Headless agent runs on well-scoped tickets — targeting 40% autonomous completion.
  • Drive knowledge layer built with retrieval-intent taxonomy.
  • Skill library expands to 15–20 versioned skills with usage metrics.
  • Client-facing artifact surfaces for UAT and requirement review.
  • Evals calibrated against Claude-specific and model-agnostic benchmarks.
Phase 3 · 18–36 months
Graceful decay of the seam
Absorb what becomes free
  • Foundation models absorb parts of the MCP layer — your seam thins, delivery velocity holds.
  • Autonomous agent completion crosses 70% on routine tickets.
  • Skill library becomes self-improving via retro feedback loops.
  • Governance function shrinks as automation maturity grows.
  • Investment compounds without platform maintenance burden.
06 · The principles

Four disciplines that must not bend.

Every failure of this architecture traces back to one of these four being violated. They are non-negotiable regardless of team size, client pressure, or vendor change.

01
Every decision has one named human owner. Never a committee, never a team. The Asana field either contains a name or the decision has not been made.
02
Every agent action is reversible, logged, and attributable. Which skill ran, which version, with which prompt, against which commit — all captured in Asana comments and MCP logs.
03
Human gates are quality checkpoints, not rubber stamps. A gate that approves 100% is not working. Healthy gates reject or revise 15–25% of submissions.
04
If it is not in Asana, it does not exist. No side channels. No private decisions in Slack. The work graph is the work. Exceptions collapse the architecture.
Own the seam. Rent the intelligence.
Ship faster than anyone still building a platform.