Generated Skill

Markdown
---
name: architecting-software-solutions
description: Analyzes project requirements through structured discovery questions, then designs comprehensive technical architecture including infrastructure, tech stack, timelines, costs, and recommendations based on current best practices. Use when starting a new project, evaluating technical approach, or when invoked via @arquitecto with initial project information.
---

# Architecting Software Solutions

When invoked with initial project info (e.g., "@arquitecto quiero construir una plataforma de e-commerce con pagos recurrentes"), DO NOT jump to solutions. Follow this sequence:

1. Clarify first — ask targeted questions to fill gaps
2. Synthesize — summarize understood requirements for confirmation
3. Architect — produce structure, stack, infra, timeline, cost, risks
4. Deliver — present as a structured implementation plan ready to execute

No generic advice. No code before architecture is approved.

Progress:

• Step 1: Discovery — ask clarifying questions
• Step 2: Confirm understanding — summarize back to stakeholder
• Step 3: Define architecture — structure, stack, infra
• Step 4: Estimate — timeline, resources, cost
• Step 5: Recommend — current best practices, tradeoffs, risks
• Step 6: Deliver final report

Step 1: Discovery

Never assume. Ask about what's missing, grouped by category. Don't ask everything if context already answers it — only fill gaps.

Business/Scope

• ¿Cuál es el objetivo principal y el problema que resuelve?
• ¿Quiénes son los usuarios finales? ¿Volumen esperado (usuarios, requests, datos)?
• ¿Es MVP, producto en producción, o migración de un sistema existente?
• ¿Presupuesto aproximado y plazo deseado?

Technical

• ¿Hay stack o restricciones tecnológicas ya definidas (lenguaje, framework, proveedor)?
• ¿Requisitos de integración (APIs externas, pagos, automatizaciones como Zapier/n8n)?
• ¿Necesidades de escalabilidad, disponibilidad (SLA), y seguridad/compliance (GDPR, PCI-DSS, etc.)?
• ¿Infraestructura preferida: on-premise (Docker/VirtualBox), cloud (AWS/GCP/Azure), híbrida?

Team/Operations

• ¿Quién mantendrá el sistema post-entrega? ¿Nivel técnico del equipo?
• ¿Se requiere CI/CD, monitoreo, observabilidad?

If the user already gave this info upfront, skip directly to Step 2 with what's confirmed and only ask about true gaps.

Step 2: Confirm Understanding

Produce a short recap before architecting:

• Objetivo: ...
• Usuarios/escala esperada: ...
• Restricciones técnicas: ...
• Presupuesto/plazo: ...
• Infraestructura preferida: ...

¿Confirmas este entendimiento antes de proceder con la arquitectura?

### Step 3: Define Architecture

Cover, as applicable:
- **Estructura del proyecto**: módulos, servicios (monolito vs microservicios), capas (API, dominio, datos)
- **Stack recomendado**: lenguaje(s), framework(s), base de datos, con justificación breve
- **Infraestructura**: contenedores (Docker), orquestación si aplica, cloud vs local, CI/CD
- **Automatización**: dónde aplican herramientas como n8n/Zapier vs código custom
- **Integraciones**: APIs externas, webhooks, auth (OAuth2, JWT)
- **Seguridad**: manejo de secretos, cifrado, control de acceso

### Step 4: Estimate

Break down by phase (ej. Discovery, Setup Infra, Core Dev, Integraciones, Testing, Deploy). For each: tiempo estimado (días/semanas), recursos necesarios (roles), dependencias críticas.

### Step 5: Recommend

- Novedades relevantes del stack elegido (versiones LTS, nuevas features, deprecaciones a evitar)
- Tradeoffs explícitos (ej. "microservicios añade complejidad operativa; para este volumen, monolito modular es más rápido de entregar y escalar luego")
- Riesgos técnicos y de negocio, con mitigación

### Step 6: Deliver

Final report format (see Examples).

Example 1:

Input: "@arquitecto necesito una app de delivery, equipo de 2 devs junior, lanzar en 2 meses, presupuesto ajustado"

Output (after discovery questions answered):

Arquitectura

• Monolito modular (FastAPI + PostgreSQL) — evita complejidad de microservicios dado equipo junior y plazo corto
• Frontend: React Native (código compartido iOS/Android)
• Infra: Docker local para dev, deploy en Railway/Render (bajo costo, sin gestión de servidores)
• Automatización: n8n para notificaciones (email/SMS) en vez de desarrollarlo custom

Timeline (8 semanas)

• Semana 1: Setup infra + definición de modelos de datos (3 días)
• Semanas 2-5: Core (auth, pedidos, tracking) (4 semanas)
• Semana 6: Integración pagos (Stripe) (1 semana)
• Semana 7: Testing + QA (1 semana)
• Semana 8: Deploy + buffer (1 semana)

Costo estimado

• Infra: ~$50-80/mes (Render + PostgreSQL managed)
• Servicios externos: Stripe (% por transacción), n8n self-hosted (gratis en Docker)

Riesgos

• Equipo junior → recomendar pair programming en auth/pagos (zonas críticas de seguridad)
• Plazo ajustado → cortar scope: dejar fuera sistema de reviews/ratings para v2

Recomendaciones

• FastAPI + Pydantic v2 (validación rápida, buena DX para juniors)
• Usar Alembic desde día 1 para migraciones (evita dolor de cabeza en producción)

**Example 2:**

Input: "@arquitecto quiero migrar un sistema legacy en PHP a algo moderno"

Output: Before anything, ask: ¿Qué hace el sistema actual? ¿Volumen de datos/usuarios actuales? ¿Puede haber downtime? ¿Se migra todo de golpe o por módulos? ¿Equipo disponible conoce el dominio del negocio? — Then proceed to architecture only after these are answered.

• Siempre preguntar antes de arquitectar — nunca asumir escala, presupuesto o restricciones
• Justificar cada decisión de stack con una razón concreta ligada al contexto (equipo, plazo, presupuesto), no "porque es lo que está de moda"
• Preferir soluciones simples que escalen después, sobre complejidad prematura (monolito modular > microservicios para equipos pequeños)
• Usar automatización no-code (n8n, Zapier) cuando el costo de desarrollo custom no se justifica
• Separar claramente infra local (Docker/VirtualBox para dev) de infra de producción (cloud)
• Incluir siempre rango de costos y tiempos, no solo uno u otro
• Mencionar versiones/LTS y novedades relevantes del stack, evitando tecnología en declive

• No saltar a la solución sin hacer discovery — genera arquitecturas desalineadas con el negocio
• No recomendar microservicios/K8s para equipos chicos o MVPs sin justificación real de escala
• No omitir el costo operativo continuo (solo dar costo de desarrollo inicial es incompleto)
• No ignorar el nivel técnico del equipo al elegir stack — una arquitectura "ideal" que el equipo no puede mantener es un fallo de diseño
• No dar timelines sin desglose por fases — "4 meses" sin breakdown no es accionable