Choosing Spec Level

​

Fast Spec: When to Use

Structure: Milestones > User Stories Best for:

• MVPs and prototypes
• Personal/side projects
• Rapid iteration workflows
• Solo developers
• When you’ll figure out implementation details as you go

What you get:

• High-level milestones
• User stories for each feature
• Basic acceptance criteria
• No granular subtasks

Cost: 10 credits Typical Use Cases:

• Weekend projects
• Proof-of-concept builds
• Small utility applications
• Learning new technologies
• Quick validation of ideas

​

Deep Spec: When to Use

Structure: Milestones > User Stories with Acceptance Criteria > Granular Subtasks Best for:

• Enterprise applications
• Complex architectures
• Team coordination
• Mission-critical systems
• When you need implementation-level planning

What you get:

• Detailed milestones
• User stories with comprehensive acceptance criteria
• Granular implementation subtasks
• Task-level breakdown for delegation

Cost: 50 credits Typical Use Cases:

• Large-scale applications
• Multi-team projects
• Regulated industries (healthcare, finance)
• Systems with complex business logic
• Applications requiring detailed audit trails

​

Feature Comparison

​

Cost-Benefit Analysis

​

Fast Spec Economics

• Cost: 10 credits (depending on your plan)
• Processing Time: 30-40 seconds
• Implementation Time: 2-4x longer (figure out details during development)
• Best for: Projects where speed-to-idea matters more than detailed planning

​

Deep Spec Economics

• Cost: 50 credits (depending on your plan)
• Processing Time: 2-3 minutes
• Implementation Time: 1.5-2x faster (detailed guidance reduces unknowns)
• Best for: Projects where thorough planning prevents costly mistakes

​

Decision Framework

​

Ask Yourself:

1. How large is the project?
   • Small (1-2 weeks): Fast Spec
   • Medium (1-3 months): Fast Spec or Deep Spec
   • Large (3+ months): Deep Spec
2. How many people will work on it?
   • Solo: Fast Spec
   • Small team (2-5): Fast Spec
   • Large team (5+): Deep Spec
3. What’s the domain complexity?
   • Simple CRUD: Fast Spec
   • Complex business logic: Deep Spec
   • Regulated industry: Deep Spec
4. What’s your risk tolerance?
   • High (can pivot quickly): Fast Spec
   • Medium (some planning needed): Fast Spec
   • Low (detailed planning required): Deep Spec
5. What’s your timeline?
   • ASAP: Fast Spec (faster generation)
   • Planned: Either (depends on other factors)

​

Quick Decision Rules

• If ANY of these are true, use Deep Spec:
  • Enterprise/commercial application
  • 3+ month timeline
  • 5+ person team
  • Mission-critical functionality
  • Complex domain (healthcare, finance, etc.)
• Otherwise, use Fast Spec

​

Documentation Scraping with Both Levels

Both Fast Spec and Deep Spec support documentation scraping:

• Option: Provide documentation URLs for any external APIs, frameworks, or services
• Automatic: Documentation is scraped in parallel (no additional time)
• Archived: Each platform gets its own organized ZIP file
• Benefit: Complete context for your development team

Example Use Cases:

• Stripe API documentation for payment processing
• React/Vue/Angular documentation for frontend architecture
• AWS/GCP/Azure documentation for infrastructure
• HIPAA/GDPR compliance documentation for regulated industries
• Third-party service APIs for integrations

See Documentation Scraping Guide for details.

​

Examples

​

Fast Spec Projects

• Personal blog website
• Simple task tracker
• Recipe collection app
• Local event finder
• Portfolio website

​

Deep Spec Projects

• Healthcare patient management system
• Financial trading platform
• Enterprise CRM system
• Multi-tenant SaaS platform
• Complex e-commerce marketplace

​

Changing Your Mind

Generated the wrong level? No problem!

• Fast Spec too basic? Generate a Deep Spec with the Fast Spec as context
• Deep Spec overkill? You can still use it - just skip the granular subtasks if they’re too detailed

The beauty of Architect API is that specs are living documents. Start with what feels right, and adjust as needed.