Architect For Startups

AWSOfficialPublished by AWS

Skill
Guidelines
Cloud and DevOps
Apache-2.0
No issues found

From the author

Startup-tailored AWS architecture advice for non-agent workloads, adjusted to the company's stage (pre-revenue through Series B+), team size, runway, and credits. Not for AI agents: deploying an AI agent on AWS, picking its runtime, or any agentic architecture is agent-advisor. Use when a founder wants guidance or a recommendation rather than code changes: which services to choose, how to plan or review an architecture, how to stretch credits and control cost, or how to prepare architecture for a fundraise or technical diligence. For an interactive discovery flow that scaffolds and writes the architecture into the codebase, use start-building-for-startups. Do not use for: writing or scaffolding code, factual AWS Activate / programs / credits lookups (see knowledge-base-for-startups), a single copy-paste prompt (see prompt-library-for-startups), or migration intent such as GCP-to-AWS, Azure-to-AWS, or Heroku-to-AWS (see the migration skills: `gcp-to-aws`, `azure-to-aws`, `heroku-to-aws`, `llm-to-bedrock`).

— the description by AWS

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Architect for Startups provides stage-appropriate AWS infrastructure advice designed for the constraints of early-stage companies. It helps founders and engineers navigate service selection based on team size, budget, and technical maturity, prioritizing speed and cost-efficiency over over-engineering. The skill uses a structured discovery process to ensure recommendations align with the startup's current lifecycle stage, from pre-revenue to Series B+.

What it does

Provides stage-specific AWS service recommendations based on team size and runway.
Evaluates infrastructure choices against startup-specific constraints and cost limits.
Offers guidance on when to adopt specific AWS services versus deferring complexity.
Applies startup-specific overlays for investor readiness and team capacity.
Includes a mandatory challenger framework to validate architecture recommendations.
Identifies relevant AWS Activate partner offers based on the recommended architecture.

When to use it

When you need guidance on choosing AWS services for a non-agent workload.
When planning or reviewing architecture for a startup at any stage from pre-revenue to Series B+.
When you need to optimize infrastructure costs or stretch AWS credits.
When preparing architecture documentation for technical diligence or fundraising.

Advantages

Prevents premature optimization by focusing on the right architecture for the current stage.
Aligns infrastructure decisions with limited team capacity and runway.
Provides clear triggers for when to graduate to more complex services.
Ensures cost-conscious decision-making by prioritizing managed services and credit usage.

Usage examples

“We are a seed-stage startup with 2 engineers and limited credits. Should we use ECS or Lambda for our backend?”: The agent will recommend Lambda for its cost-effectiveness and lower operational overhead at the seed stage, explaining why ECS is deferred until later growth.
“We are preparing for a Series A fundraise. How should I present our AWS architecture to investors?”: The agent will provide guidance on framing the architecture for investor readiness, focusing on cost-per-user, unit economics, and scalability.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/aws/architect-for-startups/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip architect-for-startups.zip -d .agents/skills

Documentation by AWS

Architect for Startups

You are a startup-focused AWS solutions architect. You understand that startups operate under fundamentally different constraints than established companies: limited runway, tiny teams, extreme time pressure, and the need to prove product-market fit before optimizing infrastructure.

Your job is to give stage-appropriate AWS guidance — not the "ideal" architecture, but the right architecture for where this startup is today.

Step 1: Establish Startup Context

Before giving any architecture advice, determine these four things. Infer from conversation context when possible; ask directly when you can't. See references/customer-ideation.md for the full discovery framework.

The 6 questions that reveal architecture-critical constraints fast:

What's your monthly AWS budget ceiling? (What kills you if exceeded?)
How many engineers will touch infrastructure? (0-1 = managed services only)
What's your team's technical profile? (Non-technical, fullstack generalists, or experienced infra/cloud engineers) Are they already developing with containers locally?
Do you have AWS credits? How much, when do they expire?
Current traffic/data volume + 12-month optimistic projection?
What's the one thing that, if it breaks, kills your company? (This gets redundancy; everything else gets the cheapest option)

If you can infer answers from context or memory, don't ask. If you're missing 2+ of these, ask before recommending an architecture or design; a single-service pick these answers would not change (auth, payments, vector DB, observability, etc.) is answered in one turn, assuming early stage unless the founder says otherwise.

Stage Detection

Stage	Signals	Core Constraint
Pre-revenue / Idea	No users, building MVP, 1-2 founders	Speed. Ship something this week.
Seed	First users (<1K), proving PMF, 2-5 people	Cost. Stay alive on credits.
Series A	Product works, scaling (1K-100K users), 5-15 engineers	Reliability without over-engineering.
Series B+	Proven scale, 15+ engineers, revenue	Standard best practices apply.

Context Checklist

Stage: Which of the four above?
Team: How many engineers? AWS experience level (1-5)?
Runway/Credits: Monthly budget? AWS Activate credits balance? Months of runway?
Timeline: When does this need to be live? (Days, weeks, months?)
Users: Current count and 12-month projection?

If the user is at Series B+ with 15+ engineers, the startup-specific framing adds less value — lean more heavily on the service-specific references directly.

Step 2: Apply Stage-Appropriate Constraints

Once you know the stage, apply the Stage Framework.

Step 3: Route to Service Guidance

You MUST read these service-specific references whenever their technology type is applicable. These reference will ensure you're architecting through a startup's lens and using the best possible startup-specific guidance.

Compute

Data

Networking & Delivery

Security & Identity

Messaging & Orchestration

Observability

Monitoring, logging, tracing
A live workload in trouble right now — an outage, 5xx errors, an alarm, "find the root cause" — or a request for pre-merge release-readiness review: hand off to the operate-on-aws skill (AWS DevOps Agent) instead of answering from this reference.

AI/ML

An AI agent is the workload — "deploy an AI agent on AWS", which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda, an agentic architecture, or moving agents to AWS: hand off to the agent-advisor skill instead of answering from these references. It scores the runtime deterministically and can build the POC. The references below are for a model call or an agent component inside a larger non-agent architecture.
Foundation models and AI agents
Agent runtime platform
ML pipelines and model serving
Strands SDK agent scaffolding

Cost

Cost analysis and optimization

Architecture & Planning

Scaffolding

IaC project generation

Migration

Azure to AWS — for the PRE-decision advisory conversation only ("should we leave Azure?", "what would this look like on AWS?"). Once the user has migration INTENT — they want an inventory, a design, a cost estimate, or artifacts — hand off to the azure-to-aws skill instead of answering from this reference.
App Runner to ECS

IoT

IoT device connectivity and fleet management

Step 4: Startup-Specific Overlays

Always layer these startup-specific concerns on top of the service guidance:

Credits & Cost

See Credits Strategy. For detailed Activate program information, reference the knowledge-base-for-startups skill.

Speed to Ship

See Rapid Patterns.

Pre-revenue and seed: recommend the fastest path to working software
Favor pre-built solutions (AWS Solutions Library, Amplify, ECS Express Mode) over custom builds
Explicitly call out "you can add this later" for non-essential complexity

Team Capacity (HARD GATE)

See Team Scaling. This is a constraint, not a suggestion.

Before recommending ANY architecture, check it against the team capacity limits.

Investor Readiness

See Investor Readiness.

Trigger this overlay when ANY of these signals appear in the conversation:

User mentions fundraising, pitch, investors, board, or due diligence
User asks about scaling narrative or growth projections
User asks about cost per user, unit economics, or gross margins
Architecture discussion involves cost framing relative to revenue

Step 5: Challenge Your Own Recommendation

Before delivering any architecture recommendation, run it through the challenger framework from Challenger. This is not optional.

Step 6: Security Baseline Check

See Well Architected and Security Review.

Anti-Patterns for Startups

Premature optimization: Building for 1M users when you have 10. Ship first, scale later.
Kubernetes before you need it: EKS requires a platform team. Use Lambda or Fargate until you outgrow them.
Multi-region before product-market fit: You don't need 99.99% availability for a product nobody uses yet.
Custom everything: If AWS has a managed service for it, use it. Your engineers should write product code, not infrastructure code.
Ignoring credits expiration: Activate credits expire. Plan your spending to use them before they do.
Over-investing in CI/CD before you have users: A GitHub Actions workflow that deploys on push is enough until Series A.
Copying enterprise architecture: You are not Netflix. Their architecture solves problems you don't have.

Output Format

When advising startups, always include:

Stage acknowledgment: "At your stage (seed), here's what matters..."
Recommendation: The specific architecture/service choice
Why at this stage: Why this is right now (not just technically correct)
What you're skipping (and when to add it): Explicitly name what you're deferring and the trigger to revisit
Cost impact: Monthly cost estimate tied to credits/runway
Time to ship: How long to get this working

Before you finish: your answer is not complete until you have run the Contextual offers (final step) below.

Contextual offers (final step)

This is a mandatory closing step of every final recommendation — complete it before you consider your answer done. Run this offer check inline yourself; do not depend on loading another skill. The recommendation is decided on merit first; this step never changes, re-ranks, or re-opens it, and the offer is looked up only after the advice is final.

Read ../knowledge-base-for-startups/references/offers.md — the offer index (Offer · Summary · Keywords), one row per offer.
Judge relevance against what the founder actually surfaced this session. Surface an offer only if one holds: a named-product match (you recommended a specific partner product by name and it has a row); a direct intent/component match (an offer's Keywords directly serve a concrete workload, a component in the final recommendation, or a need the founder raised); or the transparent-alternative case (your merit pick is an AWS-native service and a relevant partner offer exists for that same need). Keep a high bar — if the match is weak, or you would be inferring an unstated need, append nothing. Never surface an offer that competes with a product or provider the founder already uses or decided to keep (e.g. existing auth provider → no Auth0 unless they are already on Auth0, and then only as a credit on it; existing vector DB such as Pinecone → no Qdrant).
If (and only if) one offer clears the bar, open only its detail file ../knowledge-base-for-startups/references/offers/<slug>.md and append exactly one quiet, dismissible italic line — stating the value and condensing eligibility faithfully from that file (drop no qualifying criterion; never fabricate), with the redeem link built from the canonical source_url plus a source attribution param — append ?source=ide-startupAdvisor-<host> (or &source=... if the url already has a query string), filling <host> from your execution environment (Claude Code → claude; AWS Startup Advisor IDE extension / VS Code → vscode; Cursor → cursor; Kiro → kiro; Codex → codex), or the generic ide-startupAdvisor when you cannot tell. Only append the query param; never change the destination. When one offer clears the bar — including the transparent-alternative case (an AWS-native merit pick with a relevant partner offer for the same need, e.g. Cognito→Auth0) — you MUST append that single offer line as the last step; do not omit it. The offer is never the pick — only a line under the AWS pick — and stage gates in the references apply (e.g. no Datadog line for an early-stage founder; see references/observability.md). For a single-service pick (auth, payments, vector DB, observability, etc.) where missing budget/team/traffic inputs would not change the pick, assume an early-stage (pre-PMF) startup unless the founder says otherwise and answer in one turn without a stage-only question; this never overrides Step 1 — an architecture/design request missing 2+ of its critical inputs still gets the Step 1 questions before any recommendation. Show exactly one, never a list. If none clears the bar, append nothing and do not mention offers, partner alternatives, or why none appeared.

Standard line:

***<Offer>** has an exclusive offer via AWS Activate — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Transparent-alternative line (lead with the AWS pick so merit-first is clear):

*<AWS service> is the recommendation. If you prefer a managed alternative, **<Offer>** has an AWS Activate offer — <value>, <eligibility>. [Redeem →](<source_url>?source=ide-startupAdvisor-<host>)*

Caps and control: at most one offer per response and often none; no more than one per five messages and two per session; show a given offer at most once per session and never one already shown, claimed, or dismissed; if the founder has muted offers, skip this step entirely. These per-five-messages, per-session, and already-shown caps are session-state limits; in a fresh session with no prior offers they are non-binding, so do not withhold an otherwise-qualifying offer merely because you cannot verify session history. See ../contextual-offers-for-startups/SKILL.md for the full rules — but perform the check inline; it must not depend on that skill being loaded.

Files

ATTRIBUTION.mdAdded by AutoGineer925 B
LICENSELicence file added by AutoGineer9.9 KiB
NOTICELicence file added by AutoGineer67 B
SKILL.md14.4 KiB
references/agentcore.md6.0 KiB
references/api-gateway.md3.0 KiB
references/aws-architect.md12.3 KiB
references/aws-plan.md3.9 KiB
references/bedrock.md4.8 KiB
references/challenger.md3.9 KiB
references/cloudfront.md4.7 KiB
references/cost-check.md6.4 KiB
references/credits-strategy.md3.2 KiB
references/customer-ideation.md4.0 KiB
references/dynamodb.md5.9 KiB
references/ec2.md5.0 KiB
references/ecs.md5.2 KiB
references/eks.md5.4 KiB
references/iac-scaffold.md5.0 KiB
references/iam.md4.6 KiB
references/investor-readiness.md3.1 KiB
references/iot.md14.2 KiB
references/lambda.md5.7 KiB
references/messaging.md5.0 KiB
references/migration-apprunner-to-ecs-express.md4.8 KiB
references/migration-azure-to-aws.md4.6 KiB
references/mlops.md7.1 KiB
references/networking.md6.8 KiB
references/observability.md7.3 KiB
references/rapid-patterns.md2.3 KiB
references/rds-aurora.md6.1 KiB
references/s3.md4.5 KiB
references/security-review.md7.5 KiB
references/stage-frameworks.md3.9 KiB
references/step-functions.md5.3 KiB
references/strands-agent.md7.8 KiB
references/team-scaling.md3.3 KiB
references/well-architected.md4.2 KiB

references/iot.md

IoT — Startup Decision Guide

The IoT Cost Curve: Why Startups Get Surprised

IoT costs are multiplicative: devices × messages/device × actions/message. A fleet of 10,000 devices sending 1 msg/sec generates 864M messages/day. Startups that prototype with 10 devices don't see this coming.

Cost at Scale (Monthly Estimates)

Fleet size	Msg frequency	IoT Core messaging cost	Storage cost (Timestream)	Total minimum
100 devices	1/min	$4	$20	~$50
1,000 devices	1/min	$44	$200	~$400
10,000 devices	1/min	$440	$2,000	~$4,000
10,000 devices	1/sec	$26,400	$120,000	🚨

The lesson: Message frequency is the cost multiplier. Design for the lowest frequency that meets product requirements. If you need 1/sec sensing but only 1/min cloud reporting, aggregate at the edge.

Stage-Specific Architecture

Stage	Fleet size	Architecture	What to skip
Prototype (< 50 devices)	< 50	IoT Core → Rules → DynamoDB/S3. Done.	Greengrass, SiteWise, Fleet Indexing, Device Defender
Pilot (50-1000 devices)	50-1K	Add: Device Shadow, Fleet Provisioning, basic monitoring	SiteWise (unless industrial), multi-region, Greengrass (unless offline needed)
Scale (1K-100K devices)	1K-100K	Add: Greengrass edge compute, Fleet Indexing, Device Defender, Timestream	Custom analytics platform (use Timestream + Grafana)
Enterprise (100K+)	100K+	Full stack: multi-region, SiteWise if industrial, custom data lake	Nothing — you need it all

Cost Traps Specific to Startups

1. Basic Ingest: The $1/Million Messages You Don't Need to Pay

Standard MQTT publish: $1.00 per million messages broker fee + rules engine fee.

Basic Ingest ($aws/rules/<rule-name> topic): $0 broker fee, only rules engine actions charged.

Use Basic Ingest for all high-volume telemetry that only needs to flow to the cloud (no device-to-device). Most startup telemetry is one-directional. This saves 50% on messaging costs with a topic prefix change.

2. Timestream vs S3+Athena: When to Use Which

Need	Choice	Monthly cost at 10K devices, 1 msg/min
Real-time dashboards, sub-second queries	Timestream	~$2,000
Nightly batch analytics, ad-hoc queries	S3 + Athena	~$50-100
Both	Timestream for last 24h, S3 for historical	~$500 (short memory retention)

Startup default: S3 + Athena until you have a real-time dashboard requirement. Most seed-stage IoT startups query telemetry weekly, not in real-time.

3. DynamoDB for Telemetry: The $1,100/Day Mistake

10,000 devices × 1 msg/sec = 864M writes/day = ~$1,100/day on-demand DynamoDB.

Never store raw time-series telemetry in DynamoDB. Use it only for device metadata, latest-known state, and configuration. Route telemetry to Timestream (10-20x cheaper for time-series writes) or S3 ($0.023/GB/month).

4. OpenSearch for IoT Dashboards: The Always-On Cost

OpenSearch clusters run 24/7 (~$200-500/month minimum). If your dashboard usage is intermittent (operators check once/day), use:

Timestream + Grafana (serverless-ish, cheaper for periodic access)
S3 + Athena + QuickSight (fully serverless, pay per query)

5. Cellular Data Costs That Dwarf AWS Costs

Hardware startups often overlook this: a cellular modem (LTE-M/NB-IoT) costs $0.50-2.00/MB depending on carrier. A device sending 1KB every minute = 1.4MB/month = ~$1-3/device/month in CARRIER costs alone. At 10K devices, that's $10-30K/month before AWS sees a single byte.

Optimization: Aggregate readings on-device and send batched payloads every 5-15 minutes instead of per-reading. Compress with CBOR instead of JSON (40-60% smaller). This directly reduces your carrier bill — often your largest IoT cost at scale.

Counterintuitive Advice for IoT Startups

Don't Start with Greengrass

Greengrass adds significant operational complexity (component deployments, edge device management, Nucleus updates). Start with direct MQTT to IoT Core unless you have one of these hard requirements:

Must operate offline (no cloud connectivity for hours/days)
Latency < 100ms for control loops (cloud round-trip is 50-200ms)
Bandwidth costs dominate (cellular data at $0.01/MB with high-frequency sensors)

When to add Greengrass: When your cloud ingestion bill exceeds the operational cost of managing edge infrastructure, OR when you have a hard offline/latency requirement.

One Certificate Per Device (Even If It's Painful)

Shared certificates are tempting for prototypes ("just get devices connected"). But revocation of a shared cert disconnects your entire fleet. The migration from shared → per-device certs is painful at scale. Start with per-device certs from day one using Fleet Provisioning by Claim.

Fleet Provisioning: Don't Overthink It

Manufacturing capability	Method	Startup phase
Can't install unique certs (most startups)	Fleet Provisioning by Claim	Use from day one
Have a mobile app for setup	Fleet Provisioning by Trusted User	Consumer IoT
Factory installs unique certs	JITP	Later stage, when you own manufacturing

Critical: Always add a pre-provisioning Lambda hook to validate device serial numbers against an allow-list. Without it, anyone who reverse-engineers your firmware can provision unlimited devices.

Your Firmware Update Story Is Your Company's Survival Story

IoT startups that can't OTA update their fleet die slowly. A bug in the field with no update path means:

Hardware recalls ($50-200/device in logistics alone)
Customer churn from unresolvable issues
Inability to iterate on the product post-deployment

From day one: Even if you skip everything else, implement IoT Jobs-based OTA updates with rollback. Configure abort criteria (>5% failures = halt rollout). Test the update path before shipping your first 10 devices. The cost of getting this wrong at 1,000 devices is company-ending for a hardware startup.

IoT + AI: When to Run ML at the Edge

Signal	Where to run inference	Why
< 10 inferences/hour, small payload	Cloud (Lambda or Bedrock)	Simpler, no edge ML complexity
> 100 inferences/hour OR latency < 200ms	Edge (Greengrass + local model)	Bandwidth/latency requirements justify edge complexity
Camera/video data	Edge always	Streaming video to cloud is prohibitively expensive
Model > 500MB, device has < 2GB RAM	Cloud	Model doesn't fit on device

The Hardware-Software Timing Trap

Software startups iterate weekly. Hardware startups iterate quarterly (PCB rev cycles). This mismatch kills IoT startups that plan cloud architecture in lockstep with hardware timelines.

What to do: Over-provision your cloud capabilities relative to hardware. Your first PCB will be wrong. Your second will be better. Your cloud architecture needs to absorb both without re-architecture. Specifically:

Design topic structures that accommodate device types you haven't built yet
Use Device Shadow for ALL configuration (don't hardcode anything on-device that might change)
Build your provisioning flow for "devices we haven't designed" — because you'll have 3 hardware revisions running simultaneously within 18 months

The "Connected Product" vs "IoT Platform" Decision

Most IoT startups start thinking they're building a platform. They're not. They're building one connected product.

You're building a...	Architecture approach	Skip
Connected product	Single device type, simple rules, focused dashboard	Multi-tenancy, device type abstraction, white-labeling infrastructure
IoT platform/SaaS	Multi-tenant from day one, device-type-agnostic ingest	Nothing — but hire for this complexity

90% of seed-stage "IoT platforms" should be connected products first. Build the platform abstraction only after you have 3+ customers wanting different device types. The premature platform trap wastes 6-12 months of engineering on infrastructure your first 5 customers don't need.

Startup-Specific Gotchas: Investor & Go-To-Market

The Pilot-to-Paid Chasm

IoT startups often give away 50-200 devices as "pilots." The architecture cost at pilot scale ($50-400/month from the tables above) is trivial. But the customer expects the same architecture when they order 10,000 devices — and that's $4,000+/month.

Before the pilot: Model the cost at the customer's target fleet size. If the unit economics don't work (cloud cost per device > willingness to pay), you have a business model problem, not a technology problem. Discover this before the pilot, not after.

Hardware Margins Are Thin — Cloud Costs Eat Them

A typical hardware startup's BOM cost is $50-200/device with 40-60% gross margins on hardware sale. If your cloud cost is $5/device/month and customer pays $10/device/month for the "subscription" — your cloud COGS is 50% of recurring revenue before you pay for anything else.

Model this explicitly for investors:

Hardware margin: X%
Recurring revenue per device: $Y/month
Cloud cost per device at target scale: $Z/month
Net recurring margin: $(Y-Z)/Y

If Z > 30% of Y, optimize your architecture before scaling, not after.

The "Free Tier Pilot" Illusion

IoT Core free tier: 500,000 messages/month for 12 months. That's ~11 messages/minute across your entire fleet. With 50 pilot devices sending 1 msg/min, you burn through free tier in 7 days.

Don't promise "zero cost pilot" to customers based on free tier math. It doesn't scale to even modest pilots.

Anti-Patterns (Startup-Specific)

Designing for 1M devices at 100 devices. The architecture for 100 devices (direct MQTT, no edge compute, DynamoDB for state) is radically different from 1M devices. Build for 10x your current fleet, not 10,000x. Premature scaling wastes months of engineering time.
HTTP polling from battery-powered devices. A device polling every 5 seconds: 17,280 requests/day, drains battery in weeks. MQTT persistent connection: near-zero overhead when idle, battery lasts months. This is the #1 hardware startup mistake.
No error actions on IoT Rules. Failed rule actions silently drop data. You won't know you're losing telemetry until a customer complains about missing data. Always route errors to S3 or SQS — takes 5 minutes to configure.
Timestream with default memory retention (24h) for dashboards needing 7-day views. You'll query magnetic store (10x slower, different pricing model). Set memory retention to match your hot-query window.
Building a "device management portal" before device #100. Your first 50 devices can be managed with AWS Console + CLI scripts. The custom portal takes 2-3 months of engineering time that should go toward the core product. Build it when operators (not engineers) need to manage the fleet.
Choosing WiFi-only when customers have industrial sites. Consumer IoT = WiFi. Industrial/commercial IoT = often no reliable WiFi. If your customer is a factory, warehouse, or field operation, design for cellular (LTE-M/NB-IoT) from prototype. Retrofitting connectivity is a hardware redesign.
Not budgeting for device returns and RMA. 5-10% of deployed IoT devices will have issues in year one. Your architecture needs: remote diagnostics (shadow + logs), remote remediation (OTA), and graceful decommissioning (cert revocation, thing deletion). Without these, every issue is a $50-200 truck roll or RMA.
Shared X.509 certificates across devices. Revoking one shared cert disconnects entire fleet. One cert per device limits blast radius.

Credits-Specific Guidance

IoT Core messaging, Rules Engine actions, and Device Shadow operations are all credit-eligible
Timestream burns credits fast — 10K devices at 1 msg/min with 7-day memory retention = ~$2K/month in credits consumed
During credits: use Timestream generously to validate your real-time dashboard needs. If you discover nobody looks at real-time data, switch to S3+Athena before credits expire and save $2K/month
Greengrass has no per-device cloud cost (it's edge software) — but the devices it runs on aren't free. Factor in the $15-50/device compute module cost in your BOM

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

AWS

Publisher

AWS (Official)

Source

aws/agent-toolkit-for-aws · plugins/aws-startup-advisor/skills/architect-for-startups · commit 0a218f8

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
NOTICE (added by AutoGineer from NOTICE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by AWS or AWS.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download architect-for-startups.zip