The Architecture Prompt Pack: 15 Design Prompts

I am building [describe the product in one sentence]. The primary user is [describe who they are and what they are trying to accomplish]. 

Help me build a capability map by answering these questions:

1. What are the 5-8 core capabilities this system must support on day one?
2. Which of those capabilities are table stakes (users expect them to work, but they won't choose us for them)?
3. Which capabilities are differentiating (users pick us because of these)?
4. Which capabilities are likely to grow in complexity over time as usage scales?
5. What does each capability need to do technically: process data, store state, trigger actions, communicate with external systems, or something else?

Output this as a structured list. Flag any capability where you see a common architectural trap I should watch for.

For the product I described: [paste Prompt 1 context or summarize briefly]

Help me define the implicit contract users have with this system. Specifically:

1. What response times will users consider acceptable for each major interaction (fast = under 1s, tolerable = 1-5s, okay if async = 5s+)?
2. What data do users expect to be permanent? What do they expect to be ephemeral?
3. What failure modes will users forgive (slow load, temporary error) versus what will break their trust (data loss, silent failure, wrong output)?
4. What does "the system is working" look like from the user's perspective, without them knowing anything about the underlying tech?

Use these answers to identify 3 architectural constraints I should treat as non-negotiable from the start.

I am building [product summary]. My current situation is:
- Team size: [engineers available now]
- Timeline to first working version: [weeks or months]
- Budget for infrastructure: [rough monthly ceiling]
- Expected initial user volume: [low / medium / high, with a rough number if known]
- Expected growth rate: [flat, steady, or spike-prone]
- Compliance or data requirements: [none / GDPR / HIPAA / SOC2 / other]

Given these constraints, help me:
1. Identify which architectural patterns would be over-engineered for my current stage.
2. Identify which shortcuts are safe to take now and which would create serious debt.
3. Suggest a starting architecture posture (simple + modular, or more structured from day one) with a clear rationale.
4. Flag the one constraint I listed that is most likely to change and explain how that change would affect the architecture.

I need to decide on the structural approach for [product summary]. Help me think through this clearly.

1. Lay out the honest trade-offs between a well-structured monolith, a modular monolith, and a microservices approach for a product at my stage ([team size, scale expectation, timeline]).
2. For each option, describe the failure mode: what breaks first when the team grows? When traffic scales? When the product pivots?
3. Which approach does the least damage if I choose wrong early?
4. What signals would tell me it's time to migrate from the starting choice to something more distributed?
5. Give me a specific recommendation with a one-paragraph rationale, not a list of trade-offs to "consider."

Here is a rough data model for [product or feature]: [paste your schema, ER diagram description, or rough entity list].

Pressure-test it for me:

1. Which entities are likely to grow in ways I have not anticipated? What would trigger that growth?
2. Where am I storing things in a way that makes sense now but will be painful to query at scale?
3. What relationships am I treating as simple (1:1 or 1:many) that might need to become many:many later?
4. Where does this model break if I add multi-tenancy, user roles, or audit logging later?
5. What is the one change to this model that would buy me the most flexibility without adding meaningful complexity now?

My product integrates with or will integrate with: [list the APIs, services, or external systems].

For each integration:
1. What is the failure mode if this service goes down or rate-limits us?
2. Am I treating this as a core dependency or a nice-to-have? Is that classification correct?
3. Where should I build abstraction layers so I can swap this integration without rewriting core logic?
4. Which of these integrations is most likely to change its pricing, API terms, or availability in the next 18 months?

Then give me a dependency risk ranking: which integration poses the most risk to my product's stability and why.

I need to decide whether to build, buy, or use an open-source solution for [specific component, e.g., auth, search, billing, notifications, queues].

Context:
- My team's current engineering bandwidth: [available hours per week on this]
- How central is this component to our differentiation: [core / supporting / commodity]
- Acceptable maintenance burden: [low / medium / high]
- Budget for a paid solution: [range or constraint]

Help me:
1. List the real costs of each option (time, money, flexibility, vendor risk) for my context.
2. Identify what I give up permanently if I buy or borrow instead of building.
3. Recommend one path with a clear rationale.
4. Tell me what would have to be true about my product for the wrong answer to bite me hardest.

Here is a description of how my system handles [a specific flow or the full product]: [paste description].

Run a failure mode audit:

1. Where does this system fail silently (the user thinks something worked but it did not)?
2. Where does this system fail loudly in a way that is embarrassing or trust-destroying?
3. What happens if my primary database is unavailable for 5 minutes? 30 minutes? 2 hours?
4. What happens if a third-party API I depend on starts returning errors?
5. Where is there no fallback logic at all?

Prioritize the top 3 failure modes I should address before launch and suggest a specific mitigation for each.

My product is [description]. Starting expected load is [rough number of users or requests]. We are hoping to grow to [target scale] in [timeframe].

Help me identify the inflection points where my architecture will need to change:

1. At what user or request volume does my current approach start to strain? What is the first thing that breaks?
2. What is the architectural change required at that point (add caching, shard the database, move a service out, etc.)?
3. What is the next inflection point after that, and what changes then?
4. What can I do now, at low cost, to make those future changes easier without over-engineering the current system?
5. What is the one scaling assumption I am most likely to get wrong?

I am building a B2B product. Help me think through the multi-tenancy architecture decision.

My situation:
- Number of expected tenants in year one: [number]
- Sensitivity of customer data: [low / medium / high, and why]
- Compliance requirements: [none / GDPR / HIPAA / SOC2 / contractual isolation requirements]
- Expected variance between tenants (do they all use the same feature set, or will they diverge significantly?): [describe]

1. Walk me through the shared database (row-level), shared database (schema-per-tenant), and database-per-tenant models for my context.
2. What does each model cost me in engineering complexity, infrastructure cost, and compliance posture?
3. Which model is hardest to migrate away from later?
4. Give me a specific recommendation for my situation with a one-paragraph rationale.

Here is a description of my product and its architecture: [paste description].

Help me think through the security surface:

1. Where does user data enter the system, and is it validated and sanitized at each entry point?
2. Where are my authentication and authorization boundaries? Are there any flows where a user could access another user's data through a gap in the logic?
3. What sensitive data am I storing, and is the storage approach appropriate to the sensitivity level?
4. Where am I relying on security by obscurity (assuming attackers won't know the URL, ID format, or endpoint) instead of real access control?
5. What is the most likely attack vector for a product like mine, and have I accounted for it?

Flag the top 2 risks I should address before I have real users.

My product uses AI for: [describe the AI-powered features or flows].

Help me define where the AI component boundaries should be:

1. For each AI-powered flow, what inputs does the model receive? Is that the right scope, or am I sending too much or too little context?
2. Where does the model make a decision that has a downstream effect the user cannot easily reverse? How should I handle those moments?
3. Where should I put a deterministic gate or human review step instead of letting the model decide?
4. What happens in each AI flow if the model returns a malformed output, a refusal, or a hallucinated value? Is there error handling for each case?
5. How will I know when the AI component is degrading in quality over time?

My product includes AI-powered flows where context matters across multiple steps or sessions. 

Specifically: [describe the flow, e.g., a multi-step assistant, a document editor, a project workspace].

Help me think through context and state management:

1. What context does the model need at each step to produce a useful output? Is any of that context sensitive or user-specific?
2. How should context be stored between steps (in memory, in the prompt, in a database, via embeddings)?
3. When does accumulated context become a liability (cost, privacy, noise)? How do I handle context pruning?
4. If a user returns to this flow after 7 days, what context should I restore and how?
5. What is the failure mode if context is lost mid-flow, and how should the system recover gracefully?

I am deciding which AI model(s) to use for [describe the task or product].

My requirements:
- Output type needed: [text / structured data / code / embeddings / images / other]
- Latency requirement: [real-time / async acceptable]
- Cost sensitivity: [describe the volume of calls and budget constraint]
- Privacy and data sensitivity: [can data leave my infrastructure / must it stay on-prem]

Help me:
1. What model properties matter most for this task (context window, instruction-following, structured output reliability, speed, cost per token)?
2. Where am I at risk of vendor lock-in, and what abstraction would reduce that risk without adding unnecessary complexity?
3. What happens to my product if this model is deprecated, repriced, or quietly degraded in quality with 60 days of notice? What is my fallback?
4. Should I route everything to one model, or send different tasks to different models? What does that routing cost me in complexity and evaluation overhead?
5. Give me a specific recommendation, and name the one thing about my requirements that would change your answer.

Here is my current architecture plan for [product]: [paste the plan, or summarize every decision you have made so far].

I want to know whether I am done architecting for now or still missing something that gets expensive later.

1. Sort my decisions into one-way doors (hard or costly to reverse once there is real data and real users) and two-way doors (cheap to change later).
2. For every two-way door, tell me to stop deliberating and take the simplest option available. Name them explicitly.
3. Which one-way doors do I still not have a defensible answer for? Those are the only ones worth more design time.
4. What is the smallest thing I could build in the next two weeks that would produce real information about my riskiest assumption, rather than more opinions about it?
5. Give me a straight answer: keep designing, or start building? If it is start building, tell me what to build first and why.