deployment-advisor

name	deployment-advisor
description	Use when making technology, hosting, or infrastructure decisions — recommends services, databases, and deployment strategies based on project requirements and what the user actually has available

Deployment Advisor

Overview

The most expensive infrastructure mistake is not picking the wrong service — it is picking a service you do not need. Every external dependency is a bill, a failure point, and a piece of documentation you now have to read. The second most expensive mistake is ignoring what the user already has running on their machine.

Core principle: Recommend the simplest stack that meets the project's actual requirements, using what the user already has before suggesting anything new.

No exceptions. No workarounds. No shortcuts.

The Prime Directive

NO TECHNOLOGY RECOMMENDATION WITHOUT CHECKING WHAT THE USER ALREADY HAS

If you have not inventoried the user's existing tools, runtimes, services, and running processes, you are guessing — not advising. Guessing wastes money and time.

When to Use

Required for:

• New project setup ("what database should I use?", "where should I host this?")
• Architecture decisions involving external services
• Scaling discussions ("this needs to handle more traffic")
• Cost optimization ("my AWS bill is too high")
• Migration planning ("should I switch from X to Y?")
• Any question about databases, hosting, auth, storage, or background jobs

Skip for:

• The user has already chosen their stack and is asking for implementation help
• Bug fixes within an existing deployment
• Minor config changes to an already-deployed service
• The user explicitly says "I want X, help me set it up" (respect their decision)

Cognitive Traps

Rationalization	What Is Actually True
"Everyone uses Supabase now"	The right tool depends on the project, not trends. SQLite handles more than people think.
"Cloud is always better"	A $4 VPS beats $50/mo in serverless for many workloads. Steady traffic favors fixed cost.
"More services = more professional"	Every service is a dependency, a bill, and a failure point. Fewer moving parts means fewer things break.
"They need microservices"	Most projects should be monoliths. Microservices solve organizational problems, not technical ones.
"Docker is required"	Many projects deploy fine without containerization. Docker adds complexity that small teams may not need.
"Serverless is cheaper"	Serverless is cheaper for spiky, low-volume traffic. For steady load, you are paying a premium for idle capacity you already rented.
"Managed services save time"	They save ops time but add vendor lock-in, cost, and API surface. Calculate the full trade-off.

Decision Framework

Before recommending anything, complete these four steps in order.

Step 1: Assess Project Requirements

Determine what the project actually needs — not what it might need someday.

Classify each requirement as:
- REQUIRED NOW: The project cannot launch without it
- REQUIRED SOON: Needed within the first month post-launch
- NICE TO HAVE: Would be useful but the project works without it
- SPECULATIVE: "We might need this eventually"

Only recommend infrastructure for REQUIRED NOW and REQUIRED SOON.
Everything else is premature optimization.

Common project needs to evaluate:

Need	Questions to Ask
Database	How much data? How many concurrent users? Read-heavy or write-heavy? Relational or document?
Auth	How many users? Social login needed? Role-based access? Enterprise SSO?
File storage	How large are the files? How many? Public or private? CDN needed?
Background jobs	How frequent? How long-running? Retry logic needed?
Real-time	WebSocket? Server-sent events? Polling is fine?
Email	Transactional only? Marketing? Volume per month?
Payments	One-time? Subscriptions? Marketplace with splits?
Search	Full-text? Faceted? Can the database handle it?

Step 2: Cross-Reference with System Inventory

Invoke godmode:environment-awareness to get the user's system inventory.

Check for:
- Databases already installed (PostgreSQL, MySQL, SQLite, Redis, MongoDB)
- Container tools (Docker, Podman, containerd)
- Cloud CLIs (aws, gcloud, az, vercel, fly, railway, netlify)
- Runtime environments (Node.js, Python, Go, Rust, Java)
- Package managers and lockfiles (reveals the ecosystem)
- Running services (check ports 3000, 5432, 6379, 27017, 8080)
- Existing project dependencies (check package.json, requirements.txt, go.mod)
- .env files or config that reference existing services

The rule: If the user already has PostgreSQL running, do not recommend Supabase for the database. If they have the Vercel CLI and a Next.js project, Vercel is the obvious hosting choice. Work with what exists.

Step 3: Evaluate Options with Trade-Offs

For each infrastructure need, present honest trade-offs.

Step 4: Present the Recommendation

Format your output using the structure in the "Presenting the Recommendation" section below.

Stack Decision Matrix

Database

Option	Best When	Cost	Complexity	Watch Out For
SQLite	Single-server, <100 concurrent writers, read-heavy	Free	Minimal	No concurrent writes, no replication, file-based
PostgreSQL	Multi-user, relational data, complex queries, ACID needed	Free (self-hosted) / $0-15/mo (managed)	Moderate	Needs a server process, connection pooling at scale
Supabase	Need real-time, auth bundled, PostgreSQL without ops	Free tier / $25/mo pro	Low (managed)	Vendor lock-in, row-level security learning curve
PlanetScale	MySQL at scale, branching workflow, serverless-friendly	Free tier / $29/mo	Low (managed)	MySQL dialect, no foreign keys on free tier
Redis	Caching, sessions, pub/sub, leaderboards	Free (self-hosted) / $0-5/mo	Low	Not a primary database, data loss risk without persistence config
MongoDB	Document-shaped data, flexible schema, prototyping	Free tier (Atlas) / varies	Moderate	Schema discipline still needed, joins are painful

Hosting

Option	Best When	Cost	Complexity	Watch Out For
Vercel	Next.js, static sites, JAMstack, serverless functions	Free tier / $20/mo pro	Minimal	Vendor lock-in, serverless limits, build minute caps
VPS (Hetzner/DigitalOcean)	Steady traffic, full control needed, Docker workloads	$4-20/mo	Moderate (you manage it)	You own uptime, security patches, backups
Railway / Render	Quick deploy, small teams, database + app together	Free tier / $5-20/mo	Low	Costs scale fast, less control than VPS
Fly.io	Global edge deployment, containers, low latency worldwide	Pay-as-you-go / ~$5/mo base	Moderate	Newer platform, debugging deploys can be harder
AWS / GCP / Azure	Enterprise, complex infra, team with DevOps experience	Varies wildly	High	Bill shock, complexity explosion, needs dedicated ops knowledge
Cloudflare Pages/Workers	Static sites, edge compute, already using Cloudflare	Generous free tier	Low-Moderate	Worker limits (CPU time, memory), non-standard runtime

Auth

Option	Best When	Cost	Complexity	Watch Out For
NextAuth / Auth.js	Next.js project, social login, self-hosted control	Free	Moderate	Config complexity, session strategy choices, migration pain
Supabase Auth	Already using Supabase for database	Included with Supabase	Low	Tied to Supabase ecosystem
Clerk	Need polished UI components, fast integration	Free tier / $25/mo	Low	Cost scales with MAU, vendor lock-in
Auth0	Enterprise SSO, compliance requirements, large org	Free tier / $23/mo	Moderate	Complex dashboard, expensive at scale
Roll your own	Very simple needs (API key, single admin), or deep expertise	Free	High (you own security)	You own every vulnerability. Do not do this for user-facing auth unless you know exactly what you are doing.

File Storage

Option	Best When	Cost	Complexity	Watch Out For
Local filesystem	Dev only, single server, small files	Free	Minimal	Lost on redeploy, no CDN, no replication
Cloudflare R2	S3-compatible, no egress fees, already on Cloudflare	Free tier / pay-per-use	Low	Newer service, smaller ecosystem than S3
AWS S3	Industry standard, enterprise, complex access policies	Pay-per-use (egress costs add up)	Moderate	Egress fees are the hidden cost. Budget for them.
Supabase Storage	Already using Supabase	Included with Supabase	Low	Tied to Supabase, size limits on free tier

Background Jobs

Option	Best When	Cost	Complexity	Watch Out For
Simple cron / setTimeout	Periodic tasks, low volume, acceptable failure	Free	Minimal	No retry logic, no job queue, no persistence
BullMQ	Node.js project, need retries, job scheduling, Redis available	Free (needs Redis)	Moderate	Requires Redis, monitoring setup recommended
Inngest	Event-driven, serverless-friendly, need step functions	Free tier / paid	Low-Moderate	Vendor dependency, newer platform
pg-boss	PostgreSQL project, do not want Redis, moderate volume	Free (uses your PostgreSQL)	Low-Moderate	Adds load to your database, not for high throughput

Decision Flowchart

digraph deployment_advisor {
    rankdir=TB;
    node [shape=box, style=filled];

    start [label="Infrastructure Decision\nNeeded", fillcolor=lightyellow, shape=doublecircle];
    inventory [label="Step 1: Assess Project Needs\nClassify as REQUIRED NOW\nREQUIRED SOON / NICE TO HAVE", fillcolor="#e3f2fd"];
    env_check [label="Step 2: System Inventory\nInvoke environment-awareness\nCheck installed tools + services", fillcolor="#e3f2fd"];
    already_have [label="Does the user already\nhave a suitable tool?", fillcolor="#fff3e0", shape=diamond];
    use_existing [label="Recommend existing tool\nExplain how it fits", fillcolor="#e8f5e9"];
    evaluate [label="Step 3: Evaluate Options\nCompare cost, complexity,\nfit for project size", fillcolor="#e3f2fd"];
    simple_check [label="Is the simplest option\nsufficient?", fillcolor="#fff3e0", shape=diamond];
    recommend_simple [label="Recommend simplest option\nNote when to upgrade", fillcolor="#e8f5e9"];
    recommend_scaled [label="Recommend scaled option\nExplain why simple\nis not enough", fillcolor="#e8f5e9"];
    present [label="Step 4: Present Recommendation\n+ Alternative\nwith honest trade-offs", fillcolor="#e8f5e9", shape=doublecircle];

    start -> inventory;
    inventory -> env_check;
    env_check -> already_have;
    already_have -> use_existing [label="yes"];
    already_have -> evaluate [label="no"];
    use_existing -> present;
    evaluate -> simple_check;
    simple_check -> recommend_simple [label="yes"];
    simple_check -> recommend_scaled [label="no"];
    recommend_simple -> present;
    recommend_scaled -> present;
}

MCP Integration Assessment

When evaluating a project's stack, also consider whether AI integration would add genuine value. This is not about adding AI for its own sake — it is about identifying cases where an MCP server or Claude integration solves a real problem.

Consider MCP integration when:

• The project has an API that users or internal teams query frequently (an MCP server lets Claude interact with it directly)
• The project involves content management, knowledge bases, or documentation (Claude can help users find and synthesize information)
• The project has complex admin operations that benefit from natural language interfaces
• Customer support workflows could benefit from an AI agent with access to project data

Do NOT suggest MCP integration when:

• The project is a simple CRUD app with no complex query patterns
• Adding AI does not solve a problem the user actually has
• The user has not expressed interest in AI features
• It would be a gimmick rather than a genuine productivity improvement

If MCP integration is warranted:

MCP Integration Opportunity:
- Use case: [specific problem it solves]
- Implementation: MCP server exposing [which endpoints/data]
- Effort: [estimate]
- Value: [what the user or their users gain]

Presenting the Recommendation

Format your output as:

## Deployment Recommendation: [Project Name or Type]

### Project Requirements
- [Requirement 1]: REQUIRED NOW
- [Requirement 2]: REQUIRED SOON
- [Requirement 3]: NICE TO HAVE (defer)

### System Inventory
- Already installed: [tools, databases, CLIs detected]
- Running services: [ports, processes found]
- Project ecosystem: [framework, package manager, existing dependencies]

### Recommended Stack

| Layer | Choice | Reason |
|-------|--------|--------|
| Database | [choice] | [why — reference what user already has] |
| Hosting | [choice] | [why] |
| Auth | [choice] | [why] |
| [other] | [choice] | [why] |

Estimated monthly cost: $[X] (at current scale)

### Alternative Stack
[For when requirements change or scale increases]

| Layer | Choice | When to Switch |
|-------|--------|---------------|
| Database | [alt] | [trigger — e.g., "if concurrent users exceed 1000"] |
| Hosting | [alt] | [trigger] |

### What I Deliberately Did Not Recommend
- [Service X]: [why not — e.g., "overkill for this project size"]
- [Service Y]: [why not — e.g., "you do not have Docker installed and do not need it"]

Keep the recommendation proportional to the project. A weekend project gets a short recommendation. An enterprise SaaS gets thorough treatment.

Guardrails

Never:

• Recommend a service without checking if the user already has an alternative installed
• Suggest a paid service when a free alternative covers the requirements
• Recommend Docker to someone who does not have it and does not need it
• Default to AWS/GCP/Azure for projects that do not need enterprise cloud
• Stack multiple managed services when one would suffice (do not use Supabase + Auth0 + separate hosting when Supabase covers all three)
• Recommend based on what is trendy instead of what fits
• Ignore cost — always include a monthly estimate
• Suggest microservices for a project that should be a monolith

Always:

• Run environment-awareness inventory before making recommendations
• Present at least one recommended stack and one alternative
• Include cost estimates (even rough ones)
• Explain when to upgrade from the simple recommendation to the alternative
• Mention what you deliberately did not recommend and why
• Bias toward fewer services, lower cost, and less complexity
• Respect the user's existing choices when they have already committed to a stack

Connections

This skill integrates with the GodMode workflow at infrastructure decision points:

• godmode:environment-awareness -- Provides the system inventory this skill depends on. Always invoke before making recommendations.
• godmode:rationale -- Rationale surfaces alternatives at the feature level; deployment-advisor deepens the analysis for infrastructure-specific decisions.
• godmode:system-design -- Works together for architecture decisions. System-design handles application architecture; deployment-advisor handles infrastructure and services.
• godmode:project-bootstrap -- Deployment-advisor runs during project setup to establish the initial stack before any code is written.
• godmode:security-protocol -- Auth and hosting recommendations must align with security requirements.