The Blueprint Prompt Playbook

You are a senior solution architect with 12+ years building high-concurrency SaaS platforms. A client has briefed you on their project. Produce a complete, client-ready technical architecture blueprint. CLIENT PROJECT BRIEF: Platform name: [PLATFORM NAME] Industry: [INDUSTRY / VERTICAL] Description: [2–3 sentences: what it does, who uses it, core workflow] Number of modules: [N] Module names: [LIST THEM] User roles: [LIST ROLES] Compliance requirements: [HIPAA / SOC2 / GDPR / PCI / none] Expected scale: [USERS / GEOGRAPHY / GROWTH RATE] Key technical constraints: [OFFLINE-FIRST / REAL-TIME / HIGH-CONCURRENCY / PDF GENERATION / etc.] Client's stated non-negotiables: [QUOTE THEIR EXACT WORDS] Produce a blueprint with these exact sections: ## EXECUTIVE SUMMARY Platform purpose, target users, the core technical challenge this architecture solves. ## RECOMMENDED TECH STACK Layer-by-layer. For each technology: name, version, 2-sentence justification. Include: Frontend, Backend, Database, Cache, Queue, Auth, File Storage, PDF Generation (if needed), Deployment, Observability. ## DATABASE ARCHITECTURE Entity groups by module. For each: tables, key columns, relationships. Which tables must be append-only. Estimated total entity count. ## API ARCHITECTURE For each module: key endpoints (method + path + description). Which require special handling (async, streaming, webhooks). ## PERMISSION MATRIX [ROLES] × [MODULES] table. Values: FULL / READ / OWN-ONLY / NONE. Include a legend. ## CONCURRENCY & ASYNC STRATEGY For the hardest concurrency problem in this platform: describe the exact pattern (event-driven, queue-based, optimistic locking) with step-by-step data flow. ## PDF / DOCUMENT GENERATION STRATEGY (if applicable) Tool choice, async vs sync, template approach, storage and delivery method. ## DEPLOYMENT ARCHITECTURE Hosting topology. Services, their hosting, how they communicate, scaling strategy. ## RISK REGISTER Top 5 architectural risks specific to this platform. For each: risk, likelihood, impact, mitigation. ## DEVELOPMENT ROADMAP Phase 1 (foundation) / Phase 2 (core modules) / Phase 3 (advanced features). What to build in what order and why. Format: Clean markdown. Use tables. Be decisive - make recommendations, no hedge language.

You are helping me win a contract. I need a 1-page architecture overview that demonstrates I understand the client's problem deeply - before being hired. CLIENT JOB POST SUMMARY: [PASTE THE JOB POST OR SUMMARIZE IN 3–5 SENTENCES] MY POSITIONING: I specialize in [YOUR SPECIALIZATION]. I've built [REFERENCE PROJECT] which involved [RELEVANT PARALLEL TO THIS ROLE]. Produce a 1-page overview with: ## THE CORE CHALLENGE Name the hardest technical problem in this project - not the features, the underlying systems challenge. 2–3 sentences. This should make them think "they get it." ## PROPOSED ARCHITECTURE 3–5 bullet points describing the system design approach. Lead with the non-obvious choice. ## TECH STACK BET "If I were starting this today, I would bet on:" - one line per layer (Frontend / Backend / Database / Queue / Deploy). Justify the stack in 3 sentences total. ## DELIVERABLES I WOULD PRODUCE FIRST 4–5 artifacts to create before any production code. Include: ERD, permission matrix, API contract, deployment diagram. ## THE QUESTION THAT CHANGES EVERYTHING One question about their requirements that, depending on the answer, would fundamentally change the architecture. Demonstrates depth of thinking. Tone: Confident, technical, direct. No buzzwords. Write like a founder talking to another founder.

I just had a discovery call with a client. Convert my notes into a technical blueprint to send as a follow-up deliverable. CALL NOTES: [PASTE YOUR RAW NOTES - MESSY IS FINE] Instructions: 1. Extract: platform name, modules mentioned, roles, compliance needs, scale, constraints, pain points 2. Fill reasonable assumptions for anything not mentioned - flag each with [ASSUMED] 3. Produce the full blueprint using this structure: ## WHAT WE HEARD Summary of the client's problem in your own words. They should read this and feel understood. ## WHAT WE RECOMMEND Tech stack + architecture approach in 5 bullet points. Decision-focused, not exploratory. ## THE BLUEPRINT ERD summary · API overview · permission matrix · deployment · risk register ## NEXT STEPS 3 specific actions: what you need from them, what you'll produce, proposed timeline. ## OPEN QUESTIONS Things that would meaningfully change the architecture if answered differently. Presented as questions, not concerns. Tone: Professional but direct. This document will be shared internally. Make them look smart for calling you.