ArchtSoft – AI generates software architecture from requirements
- 6 architecture pattern suggestions with comparative scoring - Industry-specific tech stack recommendations (FinTech, Healthcare, etc.) - Editable architecture diagrams - Security models, compliance docs, IaC code
*The problem I'm solving:* Teams spend 2-3 weeks debating architecture decisions. I wanted to compress this to 2-3 hours with AI-powered analysis.
*Example:* Upload a BRD for a payment system → Get microservices vs monolith comparison → Choose one → Get complete diagram with Stripe, PostgreSQL, Redis recommendations → Export IaC code
*Try it:* https://archtsoft.com
*Challenges I'm facing:* 1. Hard to get feedback (Indian users are polite but silent) 2. Uncertain if AI quality is good enough for production 3. Too many features? Should I simplify?
Would love brutal feedback from this community. What would make you trust AI for architecture decisions?
Your scope is broad. Patterns, stacks, diagrams, security, compliance, and IaC form a large surface. Each item needs profound logic. When one part is weak, users lose trust in the whole system. Narrowing the tool to a smaller part gives you better quality. Start with pattern selection and diagram generation. Get that right. Add other parts only when users ask for them.
Quality depends on domain context. A BRD for payments needs strict handling. People expect PCI notes, failure paths, data flow clarity, and a clear view of how the system behaves under load. Your tool should flag missing items in the BRD and ask for them. That step alone improves trust because the tool behaves like an engineer checking gaps rather than an engine producing generic output.
Incremental refinement matters. Users want to change parts and see the tool respond with updates that respect those edits. If you regenerate the whole architecture each time, they stop using the tool. Give components stable identifiers and keep diffs small.
Feedback from users in any country is rare. Engineers speak only when something breaks or when a tool changes their workflow. Add logs, track where users stop, and measure which features are seen repeatedly. That tells you which parts need focus.
If you want engineers to trust your tool, treat it as a draft generator. Show tradeoffs. Show failure modes. Point out weak parts in the BRD. Keep scope small. Produce stable diagrams. Offer short, direct reasoning for each choice. That moves the system from a template engine to a tool that respects engineering work.