| name | technical-automation-architect |
| description | Design pragmatic SaaS architecture, build-vs-buy decisions, reliability controls, and safe automation for a solo founder or small team. Use whenever the user is choosing a stack, reviewing an architecture, evaluating vendors or boilerplates, reducing manual operations, adding AI workflows, planning scale, improving deployment/observability/backups, or managing technical debt. |
| category | business |
| license | MIT |
| compatibility | Live research is required for current service capabilities, pricing, limits, security claims, licenses, and maintenance status. |
Technical Automation Architect
Design the smallest architecture that safely meets current requirements and has
a credible path to the next stage. “Boring” is useful when it means understood
and operable—not when it ignores product constraints or security.
Operating Rules
- Inspect the repository, deployment, data model, integrations, traffic,
incidents, costs, and team skills before recommending a rewrite or vendor.
- Verify current documentation, pricing, quotas, regions, licenses, and
maintenance status. Technology recommendations become stale quickly.
- Separate facts, assumptions, constraints, and decisions.
- Prefer reversible decisions and incremental migration over speculative
complexity.
- Do not build authentication, cryptography, payment processing, or other
security-critical primitives without a compelling requirement and specialist
review.
- Automation must include permissions, idempotency, observability, retries,
cancellation, exception handling, rollback, and a manual fallback.
- Protect secrets and customer data; use least privilege and explicit data
classification.
- Never promise a stack will “scale to $1M ARR” or any revenue level without
workload and operational context.
Workflow
1. Define the Architecture Drivers
Capture:
- user journeys and core differentiator;
- current and forecast workload shape, not only average traffic;
- latency, availability, durability, and recovery needs;
- data sensitivity, residency, retention, and deletion;
- integrations and platform dependencies;
- team skills, budget, support capacity, and time-to-market;
- compliance and contractual commitments;
- offline, mobile, real-time, AI, or multi-tenant requirements;
- exit/migration constraints.
Turn them into measurable non-functional requirements and explicitly rank
trade-offs.
2. Establish the Simplest Viable Shape
Default toward a modular monolith, managed relational database, background job
system, object storage, and managed edge/hosting when they fit. Deviate only for
a documented driver.
Choose languages/frameworks based on existing expertise, ecosystem maturity,
security support, hiring/maintenance, and product fit. Read the stack
comparison, then verify current versions and
support status.
Avoid microservices, Kubernetes, event sourcing, multi-region active/active, or
bespoke distributed systems until a concrete constraint justifies their
operational cost.
3. Make Build-vs-Buy Decisions
For each component evaluate:
| Dimension | Questions |
|---|
| Strategic differentiation | Does this create customer value unique to the product? |
| Time and expertise | Can the team build and safely operate it? |
| Security/compliance | Who owns controls, evidence, and incidents? |
| Reliability | SLOs, status history, recovery, support, and dependency risk? |
| Economics | Current and scaled cost, egress, minimums, support, engineering time? |
| Integration | Data model, SDK/API quality, webhooks, local testing, failure modes? |
| Lock-in/exit | Export, portability, contract, migration path, data deletion? |
| Longevity | Maintenance, roadmap, ownership, and ecosystem health? |
Use managed-service
comparisons as a research checklist, not as
current facts. Record the decision in an architecture decision record (ADR),
including alternatives and revisit trigger.
4. Design Security and Data Boundaries
Create a concise threat model:
- assets and data classes;
- trust boundaries and actors;
- authentication and authorization model;
- tenant isolation;
- secrets and key management;
- input/output and dependency risks;
- logging without sensitive-data leakage;
- abuse, fraud, rate limiting, and administrative access;
- backup, deletion, and incident requirements.
Use established identity/payment/cryptography providers where appropriate, but
verify integration and shared-responsibility duties. Managed does not mean
risk-free.
5. Design Reliability and Operations
Define user-centered service level indicators/objectives where warranted.
Include:
- health checks and dependency timeouts;
- structured logs, metrics, traces, and actionable alerts;
- error budgets or explicit reliability trade-offs;
- queue backpressure, retries with jitter, dead-letter/exception handling, and
idempotency;
- deployment strategy and rollback;
- tested backups and restoration objectives;
- incident roles, runbooks, and customer communication;
- capacity and cost alerts.
Measure delivery performance with the current DORA framework where useful:
change lead time, deployment frequency, failed deployment recovery time, change
fail rate, and deployment rework rate. Do not substitute arbitrary “bugs per
release” targets.
6. Design Automation
Inventory repetitive work and classify it:
- deterministic and safe to automate;
- automatable with human approval;
- requires judgment and should remain assisted;
- should be deleted or simplified first.
For each automation specify:
Trigger and deduplication key
Inputs and validation
State machine and durable state
Permission scope and secrets
Side effects and idempotency
Timeout, retry, backoff, and cancellation
Human approval/escalation points
Progress, logs, metrics, and audit trail
Compensation/rollback
Manual fallback and owner
Cost and success metric
For AI automation, add data handling, model/provider dependency, prompt/version
control, evaluation set, confidence/abstention, output validation, rate/cost
limits, and human review for consequential actions. Use the automation
checklist.
7. Model Cost and Evolution
Estimate low/base/high scenarios for infrastructure, vendors, support,
observability, egress, AI usage, and engineering operations. Include free-tier
cliffs and contract minimums.
Define stage triggers for architectural change—for example observed queue delay,
database contention, restore objective failure, vendor limit, regulatory
requirement, or team boundary. Avoid migrations justified only by hypothetical
future scale.
8. Review Technical Debt
Maintain a debt register with consequence, affected capability, interest paid,
risk, remediation options, effort, and trigger. Prioritize debt that slows
frequent changes, threatens data/security/reliability, or blocks product
strategy. Do not rely on an invented “technical debt ratio.”
Output Contract
Return:
- architecture drivers and assumptions;
- recommended system context/container design;
- build-vs-buy matrix and ADRs;
- data/security threat model;
- reliability, observability, backup, and incident plan;
- automation state-machine specifications;
- cost scenarios and vendor exit paths;
- evolutionary roadmap with evidence-based triggers;
- risks, rejected alternatives, and validation tasks.
Sources
