Module 1: Understanding Deployment Options

8. Project: Deployment Decision Workshop

Project Overview

This is the capstone project of Module 1. You'll take everything you learned — deployment categories, trade-offs across 5 dimensions, serverless vs containers, cost modeling, decision matrix, and stage-based strategy — and apply it to a real use case. The result is a complete decision document you could present to a team, to a manager, or include in your project's documentation.

It's not a theoretical exercise. If you have your own AI app, use that. If not, you'll use a provided case study. In both cases, the deliverable is a functional decision matrix with a documented, justified recommendation and re-evaluation conditions.

Why it matters: This decision document is the artifact with the most impact outside this guide. It's what you show in an interview when they ask you "how do you decide where to deploy?" It's what you send your tech lead when you need to justify an infrastructure investment. And it's the base you extend in Modules 7 (platforms) and 8 (capstone project) of this guide.

Project Objective

Produce a complete Deployment Decision Document that includes:

Project context and requirements
Decision matrix with weighted criteria
Evaluation of the 4 strategies
Recommendation with justification
3-month cost estimate
Re-evaluation conditions
Migration path if conditions change

Module Recap

Before starting, make sure you master these module concepts:

Capsule	Key concept	You use it for
02	4 categories (Local, Serverless, Managed, Self-hosted)	Identifying the options
03	5 dimensions (cost, complexity, scalability, control, time-to-deploy)	Defining criteria
04	Serverless vs Containers	Going deep on the main comparison
05	Cost modeling	Estimating real costs
06	Decision Matrix Framework	Structure of the deliverable
07	Project stage	Calibrating the weights

Case Study (if you don't have your own app)

DocuSearch AI

Description: Smart search API over technical documentation. Users send a question in natural language and receive an answer based on the company's internal documentation, with sources cited.

Architecture:

User → FastAPI API → Embedding search (ChromaDB) → LLM (GPT-4o-mini) → Response
                   → Redis cache (frequent responses)

Project data:

project_data = {
    "name": "DocuSearch AI",
    "type": "RAG (Retrieval Augmented Generation)",
    "stage": "Growth early",
    "team": "2 developers (backend + ML)",
    "users": {
        "current": 150,
        "expected_6_months": 500,
        "type": "internal (2000-employee company)",
    },
    "traffic": {
        "daily_requests": 3000,
        "peak_hour_multiplier": 3,
        "pattern": "weekday 9am-6pm, minimal weekends",
    },
    "technical": {
        "framework": "FastAPI",
        "llm": "GPT-4o-mini via OpenAI API",
        "embeddings": "text-embedding-3-small via OpenAI API",
        "vector_db": "ChromaDB (in-memory, ~2GB)",
        "cache": "Redis",
        "container": "Docker (Dockerfile exists)",
        "ci_cd": "GitHub Actions (basic pipeline exists)",
    },
    "constraints": {
        "budget": "$50-100/month for infrastructure",
        "compliance": "Internal data, not regulated but they prefer control",
        "latency": "<3 seconds for a complete response",
        "availability": "Business hours (not 24/7 critical)",
        "streaming": "Not required currently, nice-to-have in the future",
    },
    "current_deployment": "Local Docker Compose on the developer's laptop",
}

Deliverable Specifications

Format

A Markdown file called deployment-decision.md with the following structure:

Section 1: Project Context (10%)

# Deployment Decision: [Project Name]
Date: [Date]
Author: [Your name]
Stage: [MVP / Growth / Scale]

## Context

### Project description
[2-3 paragraphs describing what your AI app does]

### Technical data
- Framework: [FastAPI, Flask, etc.]
- LLM: [GPT-4o, Claude, etc.]
- Database: [ChromaDB, Pinecone, etc.]
- Cache: [Redis, etc.]
- Container: [Docker yes/no]
- CI/CD: [GitHub Actions, etc.]

### Requirements
- Users: [current and expected number]
- Traffic: [requests/day, pattern]
- Budget: [monthly range]
- Latency: [maximum acceptable]
- Availability: [expected SLA]
- Compliance: [restrictions]
- Special features: [streaming, GPU, etc.]

Section 2: Decision Matrix (40%)

## Decision Matrix

### Criteria and Weights

| # | Criterion | Weight | Justification |
|---|----------|------|---------------|
| 1 | [Criterion] | [Weight] | [Why this weight] |
| 2 | [Criterion] | [Weight] | [Why this weight] |
| ... | ... | ... | ... |
| **Total** | | **100** | |

### Evaluation (1-5)

| Criterion (Weight) | Local | Serverless | Managed | Self-hosted | Notes |
|-----------------|:-----:|:----------:|:-------:|:-----------:|-------|
| [Criterion 1] ([Weight]) | [1-5] | [1-5] | [1-5] | [1-5] | [Brief justification] |
| ... | ... | ... | ... | ... | ... |

### Weighted Scores

| Criterion | Local | Serverless | Managed | Self-hosted |
|----------|:-----:|:----------:|:-------:|:-----------:|
| [Criterion 1] | [weight×score] | ... | ... | ... |
| ... | ... | ... | ... | ... |
| **TOTAL** | **[total]** | **[total]** | **[total]** | **[total]** |

Section 3: Cost Estimate (20%)

## Cost Estimate (3 months)

### Breakdown by strategy

| Component | Local | Serverless | Managed | Self-hosted |
|-----------|-------|------------|---------|-------------|
| Infrastructure | $X/month | $X/month | $X/month | $X/month |
| LLM APIs | $X/month | $X/month | $X/month | $X/month |
| Ops (time) | $X/month | $X/month | $X/month | $X/month |
| **Monthly total** | **$X** | **$X** | **$X** | **$X** |
| **3-month total** | **$X** | **$X** | **$X** | **$X** |

### Cost notes
- [Assumptions about traffic]
- [Assumptions about the LLM model]
- [Identified cost risks]

Section 4: Recommendation (15%)

## Recommendation

### Chosen strategy: [Name]
**Score:** [total] of [maximum possible]

### Justification
[3-5 paragraphs explaining why this strategy is optimal
for this case. Include the 2-3 criteria that most influenced it.]

### Ruled-out options
| Option | Score | Main reason for ruling out |
|--------|-------|-----------------------------|
| [Option 2] | [score] | [Why not] |
| [Option 3] | [score] | [Why not] |
| [Option 4] | [score] | [Why not] |

Section 5: Action Plan and Re-evaluation (15%)

## Action Plan

### Steps to implement
1. [Step 1 — with a time estimate]
2. [Step 2]
3. [Step 3]
4. [Step 4]

### Timeline
| Week | Action | Deliverable |
|--------|--------|-----------|
| 1 | [Action] | [Deliverable] |
| 2 | [Action] | [Deliverable] |

## Re-evaluation Conditions

### Triggers to migrate
- [ ] [Trigger 1 with a specific metric]
- [ ] [Trigger 2]
- [ ] [Trigger 3]

### Migration path
If [trigger], migrate to [alternative strategy]:
1. [Step 1]
2. [Step 2]
3. [Step 3]

### Scheduled review
- Date: [3 months from the decision]
- Reviewer: [who]
- Data to evaluate: [metrics]

Guided Step by Step

Step 1: Document the context (15 min)

Fill in Section 1 with your project's data (or the DocuSearch AI case). Be specific with numbers — "some users" is not a valid input for a decision matrix.

# Verify that you have all the necessary data
required_data = [
    "Current number of users",
    "Estimated requests/day",
    "Monthly budget",
    "Maximum acceptable latency",
    "Does it need streaming?",
    "Are there compliance constraints?",
    "Do you have a Docker container?",
    "Do you have CI/CD?",
    "Project stage (MVP/Growth/Scale)",
]

for item in required_data:
    # If you can't answer, research before continuing
    print(f"✅ {item}: [your answer]")

Step 2: Define criteria and weights (15 min)

Select 5-7 criteria and assign weights that sum to 100. Use the 5 standard dimensions as a base and add AI-specific criteria if applicable.

# Criteria and weights template
criteria = {
    # Standard (adjust weights to your case)
    "Total monthly cost": 0,         # Includes infra + ops + APIs
    "Operational complexity": 0,     # Hrs/week of maintenance
    "Time-to-deploy": 0,             # From commit to production
    "Scalability": 0,                # Ability to grow
    "Control": 0,                    # Access to configuration

    # AI-specific (add if applicable)
    "Cold start latency": 0,         # If latency matters
    "Streaming support": 0,          # If chat with streaming
    "Memory for models": 0,          # If embeddings/models in RAM
}

# Example for DocuSearch AI (Growth, team of 2, moderate budget)
criteria_docusearch = {
    "Total monthly cost": 20,
    "Operational complexity": 20,
    "Time-to-deploy": 15,
    "Scalability": 15,
    "Control": 10,
    "Memory for models": 10,  # ChromaDB needs ~2GB RAM
    "Latency < 3s": 10,
}

assert sum(criteria_docusearch.values()) == 100

Step 3: Evaluate each strategy (20 min)

For each criterion, evaluate each strategy from 1 to 5 with justification:

evaluation_docusearch = {
    "Total monthly cost": {
        "Local": (4, "VPS $24/month + APIs $15 = $39"),
        "Serverless": (3, "Lambda $5 + APIs $15 + but ChromaDB doesn't fit in Lambda"),
        "Managed": (4, "Railway $20/month + APIs $15 = $35"),
        "Self-hosted": (1, "EC2 $30 + ops $400 + APIs $15 = $445"),
    },
    "Memory for models": {
        "Local": (5, "VPS with 4GB+ of RAM, ChromaDB fits"),
        "Serverless": (1, "Lambda max 10GB but stateless, ChromaDB doesn't persist"),
        "Managed": (3, "Railway Pro has up to 8GB but verify"),
        "Self-hosted": (5, "Unlimited, we choose the instance type"),
    },
    # ... complete the other criteria
}

Step 4: Calculate scores (10 min)

def calculate_scores(criteria: dict, evaluation: dict) -> dict:
    """Calculate weighted scores."""
    options = ["Local", "Serverless", "Managed", "Self-hosted"]
    scores = {opt: 0 for opt in options}
    details = {opt: {} for opt in options}

    for criterion, weight in criteria.items():
        for option in options:
            score, justification = evaluation[criterion][option]
            weighted = weight * score
            scores[option] += weighted
            details[option][criterion] = {
                "raw": score,
                "weighted": weighted,
                "note": justification
            }

    return {
        "totals": dict(sorted(scores.items(), key=lambda x: x[1], reverse=True)),
        "details": details,
        "max_possible": sum(criteria.values()) * 5,
    }

results = calculate_scores(criteria_docusearch, evaluation_docusearch)
print(f"Ranking: {results['totals']}")
print(f"Maximum possible score: {results['max_possible']}")

Step 5: Estimate costs (15 min)

Use the Capsule 05 calculator with your real data:

docusearch_costs = {
    "monthly_requests": 90_000,  # 3K/day × 30
    "avg_input_tokens": 800,     # RAG context + query
    "avg_output_tokens": 400,
    "embedding_requests": 90_000,
}

# LLM cost (GPT-4o-mini)
llm_cost = docusearch_costs["monthly_requests"] * (
    (800 / 1_000_000 * 0.15) + (400 / 1_000_000 * 0.60)
)
embedding_cost = docusearch_costs["embedding_requests"] * 0.0001

api_total = llm_cost + embedding_cost
print(f"API costs: ${api_total:.2f}/month")

# Infra costs by strategy
infra = {
    "Local (VPS 4GB)": 24,
    "Serverless (Lambda)": "N/A - ChromaDB doesn't fit",
    "Managed (Railway Pro)": 20,
    "Self-hosted (EC2)": 30,
}

Step 6: Write the recommendation (15 min)

With the scores and costs, write the recommendation. Include the second option and the ruled-out ones with a reason.

Step 7: Write the recommendation and ruled-out options (15 min)

Structure your recommendation in 3 parts:

### Chosen strategy: [Name]
**Score:** [total] / [maximum possible]

### Justification (3-5 paragraphs)
1. Which strategy it is and why it won
2. The 2-3 criteria that most influenced the result
3. Why the second option didn't win
4. Known risks of the chosen strategy
5. What you'd do differently if your constraints changed

### Ruled out
- [Option 2]: Score [X]. Not chosen because [main reason]
- [Option 3]: Score [X]. Not chosen because [main reason]
- [Option 4]: Score [X]. Not chosen because [main reason]

Tip: If your recommendation contradicts the highest score (for example, you chose the second option due to a deal-breaker), explain it explicitly. "Serverless won on score but was ruled out for not supporting streaming" is perfectly valid.

Step 8: Define re-evaluation conditions (10 min)

Be specific with metrics:

re_evaluation_triggers = [
    "Users > 500 active → evaluate scalability",
    "Latency p95 > 3s → evaluate more powerful infra",
    "Bill > $100/month → evaluate VPS vs managed",
    "Streaming requirement → verify platform support",
    "SOC2 compliance → evaluate self-hosted or AWS with a VPC",
]

review = {
    "date": "3 months from deploy",
    "metrics_to_check": [
        "Real traffic vs estimated",
        "Real costs vs estimated",
        "Downtime incidents",
        "User feedback about latency",
    ],
}

Completeness Checklist

Before considering the project finished, verify:

Structure

Section 1: Context with specific data (not vague)
Section 2: Decision matrix with ≥5 criteria, weights that sum to 100
Section 3: Cost estimate with real numbers for ≥3 strategies
Section 4: Recommendation with justification and ruled-out options
Section 5: Re-evaluation conditions with metrics

Quality

The weights reflect YOUR priorities (they aren't uniform)
Each evaluation (1-5) has justification (not just numbers)
The costs include APIs + infra + ops (not just infra)
The recommendation names ruled-out alternatives with a reason
There are ≥3 re-evaluation triggers with specific metrics
There is a scheduled review date

Defense

You could explain the decision in 2 minutes to a non-technical person
If a colleague questions a weight, you can justify it
If a constraint changes (more budget, more users), you know how to re-evaluate
The document is self-sufficient (someone external understands it without extra context)

Evaluation Rubric (100 points)

Section 1: Project Context (15 points)

Criterion	Points	Description
Project description	3	What the app does, what problem it solves
Complete technical data	4	Framework, LLM, DB, cache, container, CI/CD
Quantified requirements	4	Users, traffic, budget, latency — with NUMBERS
Documented constraints	4	Compliance, streaming, GPUs, availability

0 points if: The data is vague ("some users," "flexible budget")

Section 2: Decision Matrix (35 points)

Criterion	Points	Description
At least 5 relevant criteria	5	Includes the 5 standard dimensions + AI-specific if applicable
Weights sum to 100	3	Verifiable — no discussion
Differentiated weights	5	NOT uniform (not all 20). They reflect YOUR priorities
Weight justification	5	Each weight has 1 sentence explaining why that number
1-5 evaluation with justification	7	Each score has a note explaining why that number
Weighted scores calculated correctly	5	Weight × Score, no math errors
Clear ranking	5	Winner, second, and ruled-out ones are identified

0 points if: The weights are all equal or don't sum to 100

Section 3: Cost Estimate (20 points)

Criterion	Points	Description
At least 3 strategies costed	5	Ideally the 4 categories
Breakdown: infra + APIs + ops	5	Not just infra — includes the cost of your time and LLM APIs
Real numbers (not made up)	5	Based on current provider prices
3-month projection	5	With a base and pessimistic scenario

0 points if: You only cost infrastructure without including APIs or ops

Section 4: Recommendation (15 points)

Criterion	Points	Description
Chosen strategy with score	3	Clearly identified
Justification in 3-5 paragraphs	5	Explains the 2-3 criteria that most influenced it
Ruled-out options with a reason	4	Each ruled-out one has 1 sentence of why not
Consistency with the matrix	3	The recommendation matches the highest score (or explains why not)

0 points if: The recommendation contradicts the matrix without explaining why

Section 5: Re-evaluation (15 points)

Criterion	Points	Description
At least 3 triggers with metrics	5	"If traffic > 500/hour" not "if it grows a lot"
Documented migration path	5	Concrete steps if you need to change strategy
Scheduled review date	3	Specific date, not "in the future"
Metrics to check at the review	2	What data you review to decide whether to keep or migrate

0 points if: There are no re-evaluation conditions

Grading table

Range	Grade	Meaning
90-100	Excellent	Document ready to present to a tech lead
75-89	Good	Solid, with minor areas for improvement
60-74	Acceptable	Covers the basics but lacks depth
40-59	Insufficient	Missing significant content or has errors
0-39	Not passing	Doesn't demonstrate understanding of the framework

Minimal Implementation Example

This is an example of what a decision document that meets the minimum requirements looks like (grade "Acceptable," ~65 points). It's not the best possible document — it's the minimum to pass:

# Deployment Decision: DocuSearch AI

Date: 2026-03-08
Author: [Your name]
Stage: Growth early

## Context

DocuSearch AI is a RAG API that searches internal technical documentation.
150 current users, 500 expected in 6 months.
FastAPI + ChromaDB (2GB RAM) + Redis + OpenAI API.
3000 requests/day, 3x peaks during business hours.
Budget: $50-100/month. Latency: <3s. No regulatory compliance.

## Decision Matrix

### Criteria and Weights

| # | Criterion | Weight | Justification |
|---|----------|------|---------------|
| 1 | Monthly cost | 20 | Moderate budget, not constraint #1 |
| 2 | Operational complexity | 20 | Team of 2, we prefer simple |
| 3 | Time-to-deploy | 15 | Not urgent but we want to iterate |
| 4 | Scalability | 15 | Expected growth of 3x |
| 5 | Control | 10 | No special compliance |
| 6 | Memory (ChromaDB) | 10 | ChromaDB needs 2GB minimum |
| 7 | Latency < 3s | 10 | Internal SLA |
| **Total** | | **100** | |

### Evaluation and Scores

| Criterion (Weight) | Local | Serverless | Managed | Self-hosted |
|-----------------|:-----:|:----------:|:-------:|:-----------:|
| Cost (20) | 80 | 60 | 80 | 20 |
| Complexity (20) | 60 | 80 | 100 | 20 |
| Time-to-deploy (15) | 45 | 60 | 75 | 15 |
| Scalability (15) | 30 | 75 | 45 | 60 |
| Control (10) | 40 | 20 | 30 | 50 |
| Memory (10) | 50 | 10 | 30 | 50 |
| Latency (10) | 50 | 30 | 40 | 50 |
| **TOTAL** | **355** | **335** | **400** | **265** |

## Cost Estimate (3 months)

| Component | Local | Managed |
|-----------|-------|---------|
| Infra | $24/month | $20/month |
| APIs (OpenAI) | $45/month | $45/month |
| Ops (time) | $150/month | $25/month |
| **Monthly total** | **$219** | **$90** |
| **3-month total** | **$657** | **$270** |

## Recommendation

**Managed (Railway Pro)** — Score 400/500.

Railway wins for low complexity and fast time-to-deploy. The team of 2
doesn't want to spend time maintaining infra. ChromaDB fits in Railway Pro
(up to 8GB). Serverless ruled out: ChromaDB needs persistent state
that Lambda doesn't offer.

## Re-evaluation

- If users > 500 → check Railway limits
- If latency p95 > 3s → evaluate a dedicated VPS
- If bill > $150/month → evaluate a VPS as an alternative
- Review: June 2026

This example meets the minimum requirements. To reach "Excellent":

Add justification to each evaluation (1-5)
Include a pessimistic scenario in the costs
Detail the migration path step by step
Add sensitivity analysis (what happens if I change a weight?)

Project-Specific Troubleshooting

"I don't have my own AI app, do I use the DocuSearch case?"

Yes. The DocuSearch case has data real enough to produce a genuine matrix. Adjust the parameters if you want to simulate a different scenario (more users, less budget, streaming required).

"Two strategies have very close scores (<5% difference)"

Good sign — your case has no extreme constraints. Options:

Do sensitivity analysis (change a weight ±10, does the winner change?)
Choose by a non-quantifiable factor (developer experience, familiarity)
Document both as viable and choose the easiest to migrate

"Serverless doesn't work for my case (ChromaDB in memory)"

Correct. Don't force the evaluation — give it a 1 or 2 on memory criteria and document why. An honest matrix that rules out an option with data is more valuable than one that forces options that don't fit.

"My manager doesn't care about the scores, just wants an answer"

The document is for you and your future self. But for the manager, extract a 3-sentence summary: "I recommend X because Y. It costs $Z/month. We re-evaluate in N months." The detail is in the document for whoever wants to go deeper.

"I want to use a visual tool (spreadsheet, Notion)"

The format doesn't matter — what matters is the content. If you prefer Google Sheets with automatic formulas for the weighted scores, use it. This project's Markdown template is a guide, not a format requirement.

"I don't know how to estimate LLM API costs"

Use this quick formula:

# Quick LLM cost formula
monthly_requests = 3000 * 30  # req/day × 30 days
avg_tokens_per_request = 1200  # input + output average

# GPT-4o-mini: ~$0.75/1M tokens average
monthly_llm_cost = monthly_requests * avg_tokens_per_request / 1_000_000 * 0.75
# = 90,000 * 1200 / 1M * 0.75 = ~$81/month

print(f"LLM estimate: ${monthly_llm_cost:.2f}/month")

If you don't know the average tokens, use 1000-1500 as a conservative estimate for a RAG app.

"My matrix has 10 criteria and it feels too complex"

Reduce it to 5-7 criteria. Group related criteria: "Cold starts" + "Latency" → "Inference performance." More criteria doesn't mean better analysis — it means more noise. If a criterion weighs <5, it probably doesn't deserve to be a separate criterion.

"Can I change the decision after starting to implement?"

Yes, and it's more common than you think. If after 2 weeks implementing Railway you discover you need more RAM than its plan offers, migrate. Your Docker container is portable — that's the benefit of having containerized first. Update your matrix with the real data and document the change.

Tips for an Excellent Project

What separates a "Good" project from an "Excellent" one

Specific data, not generic. "50K requests/month with an average duration of 2.3 seconds" instead of "moderate traffic."
Justification in each evaluation. Not just "Serverless: Cost = 5." But "Serverless: Cost = 5 — Lambda at this volume costs $1.25/month vs $24/month for a VPS."
Sensitivity analysis included. "If I change the cost weight from 25 to 15, the winner is still Managed. The decision is robust."
Concrete migration path. Not "migrate to AWS if it grows." But "if > 10K req/day: (1) export the Docker image, (2) create an EC2 t3.medium, (3) docker compose up, (4) redirect DNS. Estimated time: 4 hours."
Honesty about uncertainty. "The scalability scoring is estimated — we don't have real data. We re-evaluate in 4 weeks with production metrics."

Functional Result

By completing this project, you'll have:

deployment-decision.md (or equivalent)
├── Context: Concrete data about your AI project
├── Matrix: 5-7 criteria × 4 strategies, weighted
├── Costs: 3-month estimate, 3+ strategies
├── Recommendation: With justification and ruled-out options
├── Re-evaluation: 3+ triggers with metrics
└── Review: Date and metrics to check

This document is:

Portfolio-worthy: Demonstrates the ability to make infrastructure decisions with criteria
Reusable: The framework applies to any future deployment decision
Extensible: It extends in Module 7 (platforms) and Module 8 (capstone project)
Defensible: Any engineer can review it, question it, and understand your reasoning

Connection to the Guide

What's next?

With your decision matrix completed:

Module 2: You'll implement the "Local" strategy with Docker Compose multi-container — regardless of your recommendation, because you need to master local deployment as a base.
Module 3: You'll implement the "Serverless" strategy with Lambda — to have the skill in your toolkit.
Modules 4-6: You'll learn AWS with LocalStack at no cost — to have the cloud option without barriers.
Module 7: You'll extend your decision matrix with platform criteria (Render vs Railway vs Fly.io vs AWS).
Module 8: You'll apply your updated decision matrix to deploy your AI system in real production.

Your Module 1 matrix is v1. The Module 7 one is v2. The Module 8 one is v_final — applied and verified with a real system.

Document evolution

Module 1 (now): deployment-decision-v1.md
  → Evaluates 4 categories, chooses a general strategy

Module 7 (future): deployment-decision-v2.md
  → Adds specific-platform criteria (Render vs Railway vs Fly.io)
  → Updates with real data if you're already in production

Module 8 (final): deployment-decision-final.md
  → Matrix applied to the system deployed in production
  → Includes real metrics, verified costs, lessons learned

Extended Technical Specifications

Deliverable format

Your deployment-decision.md must be a self-sufficient Markdown file. Anyone on the team should be able to open the file, read it top to bottom, and understand: (1) what app it is, (2) what options you evaluated, (3) why you chose what you chose, and (4) when to re-evaluate.

# Verify that your file is complete
wc -l deployment-decision.md
# Expected: 100-200 lines minimum

# Verify that it has all the sections
grep "^## " deployment-decision.md
# Expected:
# ## Context
# ## Decision Matrix
# ## Cost Estimate
# ## Recommendation
# ## Re-evaluation (or similar)

Python code quality criteria (if you include scripts)

If you include calculators or Python scripts in your document:

# ✅ Good: reusable function with parameters
def estimate_cost(monthly_requests: int, model: str = "gpt-4o-mini") -> float:
    """Estimate the monthly cost of LLM APIs."""
    prices = {"gpt-4o-mini": 0.003, "gpt-4o": 0.06}
    return monthly_requests * prices.get(model, 0.003)

# ❌ Bad: hardcoded numbers without context
cost = 50000 * 0.003  # What is 50000? What is 0.003?

Document versioning

Your decision matrix is a living document. Version it with Git:

git add deployment-decision.md
git commit -m "feat: decision matrix v1 - Module 1"

# After a re-evaluation:
git commit -m "update: decision matrix v1.1 - real data month 1"

Summary

The Deployment Decision Workshop is the capstone project of Module 1 that produces a complete decision document.
The deliverable is a deployment-decision.md file with 5 sections: context, matrix, costs, recommendation, and re-evaluation.
The 100-point rubric evaluates: context (15), matrix (35), costs (20), recommendation (15), and re-evaluation (15).
You can use the DocuSearch AI case if you don't have your own app — it has data real enough.
The weights must sum to 100 and reflect your real priorities, not uniform values.
The costs include 3 components: infrastructure + LLM APIs + operation time.
The matrix is reused and extended in Modules 7 (platforms) and 8 (capstone project).
Document when to re-evaluate with specific triggers and metrics — that's what turns a static document into a living tool.

Resources for the Project

Architecture Decision Records (ADR) — Standard format for documenting architecture decisions
AWS Well-Architected Framework — Architecture evaluation framework
Decision Matrix Template — Miro — Visual decision matrix template
Cloud Cost Calculator — Vantage — Cloud cost calculator
Railway Pricing — For estimating managed costs
DigitalOcean Pricing — For estimating VPS costs

← Previous7. Project Stage and Deployment Next →1. Introduction: Local & Container Deployment