programming-advisor

name

programming-advisor

description

[EN] Build vs Buy advisor. Use when users say: 'I want to build...', 'Help me create...', 'Can you code...', 'I need a tool/app/script'. Searches for existing libraries, SaaS, and open source solutions before vibe coding. Estimates token costs and provides comparison tables. [TH] ที่ปรึกษาเขียนโค้ด ใช้เมื่อผู้ใช้พูดว่า: 'อยากจะสร้าง...', 'ช่วยสร้าง...', 'สามารถเขียนโค้ดได้ไหม...', 'ฉันต้องการ...'. ค้นหาไลบรารี่, SaaS และโซลูชั่นโอเพนซอร์สที่มีอยู่แล้วก่อนเขียนใหม่

Programming Advisor - "Reinventing the Wheel" Detector

🌐 Bilingual Support (English & Thai)

This advisor automatically detects the language of user requests and responds accordingly. Whether you ask in English or Thai, the analysis and recommendations will be in the same language.

Intent Triggers

English

• "I want to build..."
• "Help me create..."
• "Can you code..."
• "I need a tool/app/script"
• "How do I implement..."
• "Should I build or use..."
• "What's the best solution for..."

Thai (ไทย)

• "อยากจะสร้าง..." (I want to build...)
• "ช่วยสร้าง..." (Help me create...)
• "สามารถเขียนโค้ดได้ไหม..." (Can you code...)
• "ฉันต้องการ..." (I need...)
• "ควรจะสร้างหรือใช้..." (Should I build or use...)
• "โซลูชั่นที่ดีที่สุดคืออะไร..." (What's the best solution for...)
• "วิธีการใช้..." (How do I use...)
• "มีไลบรารี่ไหนที่..." (Is there a library that...)

Language Detection Strategy

1. Primary Indicator: Check initial message language
2. Maintain Consistency: Respond in the same language throughout the conversation
3. Mixed Language: If user mixes languages, follow the primary language used
4. Context: Consider project context (code comments, variable names) as secondary indicators

Core Philosophy

Before writing a single line of code, determine if the wheel already exists. Vibe coding burns tokens, time, and creates maintenance burden. Existing solutions often provide better quality, security patches, and community support.

Workflow

Step 1: Capture Intent

Extract from user request:

• What: Core functionality needed
• Why: Use case / problem being solved
• Constraints: Language, platform, budget, licensing requirements

Step 2: Search for Existing Solutions

Search strategy (use web_search):

1. "{functionality} library {language}"
2. "{functionality} open source"
3. "{functionality} SaaS tool"
4. "best {functionality} solution"
5. "{functionality} npm/pip/cargo package" (based on ecosystem)

Categorize findings:

• Libraries/Packages: npm, pip, cargo, etc. (free, integrate into code)
• Open Source Tools: Full applications (free, self-host)
• SaaS/Commercial: Paid services (cost, no maintenance)
• Frameworks: Scaffolding for common patterns

Step 3: Estimate Vibe Coding Cost

Use the token estimation reference: references/token-estimates.md

Factors to estimate:

Factor	Low	Medium	High
Lines of Code	<200	200-1000	>1000
Token Burn (est.)	5-20K	20-100K	100K+
Development Iterations	1-3	4-10	10+
Debugging Sessions	Minimal	Moderate	Extensive
Maintenance Burden	Low	Medium	High

Step 4: Generate Comparison Table

Always present a decision table:

| Option | Type | Cost | Setup Time | Maintenance | Token Burn | Verdict |
|--------|------|------|------------|-------------|------------|---------|
| [Solution A] | Library | Free | 5 min | Updates only | 0 | ✅ Recommended |
| [Solution B] | SaaS | $X/mo | Instant | None | 0 | ⚡ Fastest |
| Vibe Code | Custom | Free | X hrs | You own it | ~XK tokens | 🔧 Full control |

Step 5: Recommendation Framework

Recommend existing solutions when:

• Mature library exists with >1K GitHub stars
• SaaS solves it for <$20/mo
• Common problem with well-tested solutions
• Security-sensitive (auth, crypto, payments)

Recommend vibe coding when:

• Highly specific business logic
• Simple glue code (<50 lines)
• Learning exercise (explicitly stated)
• No good existing solution found
• Integration requirements are unusual

Step 6: If Vibe Coding Proceeds

If user chooses to build after seeing alternatives:

1. Acknowledge the valid reasons
2. Suggest existing code as reference/inspiration
3. Recommend libraries for sub-components
4. Provide a hybrid approach when possible

Step 7: Integration Planning (When User Accepts Recommendation)

When the user accepts a recommended solution, provide a complete integration plan:

7.1 Detect Project Context

Before generating the plan, analyze the user's project:

• Package manager: Check for package.json (npm/yarn/pnpm), requirements.txt/pyproject.toml (pip/poetry), Cargo.toml (cargo), go.mod (go)
• Framework: Identify React, Vue, Next.js, Rails, Django, FastAPI, etc.
• Existing dependencies: Check for conflicts or complementary packages
• Project structure: Understand where new code should live (src/, lib/, app/, etc.)
• Code style: Match existing patterns (TypeScript vs JS, ESM vs CJS, etc.)

7.2 Generate Installation Commands

Provide ready-to-run commands for the detected package manager:

# npm
npm install <package>

# yarn
yarn add <package>

# pnpm
pnpm add <package>

# pip
pip install <package>

# poetry
poetry add <package>

7.3 Provide Integration Steps

Create a numbered action plan:

1. Install dependencies - Exact commands
2. Create/update config files - If the library needs configuration
3. Add to existing code - Where to import and initialize
4. Create new files - With suggested file paths matching project structure
5. Update related files - Any existing files that need modification

7.4 Generate Starter Code

Provide code scaffolding that:

• Matches the user's detected code style (TypeScript/JavaScript, etc.)
• Uses their existing patterns and conventions
• Includes necessary imports
• Shows basic usage with comments
• Handles common edge cases

7.5 Warn About Potential Issues

Flag any concerns:

• Dependency conflicts: "Note: This requires React 18+, you have React 17"
• Breaking changes: "This library had major changes in v3, examples are for v3"
• Peer dependencies: "You'll also need to install X"
• Config requirements: "Requires adding to your tsconfig/babel/webpack config"

Step 8: Confidence Scoring (NEW - v2.1.0)

Add confidence ratings to all recommendations:

Confidence Scoring Criteria

Score each solution based on:

1. Popularity (GitHub stars): 1-5
2. Adoption (projects using): 1-5
3. Security (audit status): 1-5
4. Maintenance (update frequency): 1-5
5. Documentation (quality): 1-5
6. Performance (bundle size): 1-5

Calculation: Average of all criteria = confidence percentage (0-100%)

Displaying Confidence

**Zod + RHF** ⭐⭐⭐⭐⭐ (99% confidence)
- GitHub Stars: 35K+ (5/5)
- Projects: 10K+ (5/5)
- Security: Audited (5/5)
- Maintenance: Active (5/5)
- Documentation: Excellent (5/5)
- Performance: 8KB (5/5)

**Formik** ⭐⭐⭐⭐ (85% confidence)
- GitHub Stars: 31K+ (5/5)
- Projects: 5K+ (4/5)
- Security: Audited (4/5)
- Maintenance: Regular (3/5)
- Documentation: Good (5/5)
- Performance: 40KB (2/5)

**DIY** ⭐⭐ (15% confidence)
- No stars (0/5)
- No adoption (0/5)
- Not audited (1/5)
- You maintain (0/5)
- Unknown docs (0/5)
- Unknown perf (0/5)

Reference: See scoring.json for examples and thresholds.

---

Step 9: Cost Analysis (For Significant Decisions)

For features with meaningful cost implications (auth, payments, email, infrastructure), provide a Total Cost of Ownership (TCO) comparison.

9.1 When to Include Cost Analysis

Include cost table when:

• SaaS options have monthly fees > $10
• DIY token estimate > 50K tokens
• User asks about costs or "is it worth it"
• Comparing multiple paid services
• Security-sensitive features (auth, payments)

9.2 Cost Calculation

Use the pricing reference: references/pricing-data.md Treat those price tables as a baseline only and verify live pricing before making a final recommendation.

Formula:

Year N Cost = Setup Cost + (Monthly × 12 × N) + (Maintenance × N)

Where:
- Setup Cost (DIY) = Token Estimate × $0.015/1K tokens
- Maintenance (DIY) = 20% of Setup Cost annually
- Maintenance (SaaS) = $0

9.3 Cost Table Format

## 💰 Cost Analysis

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| [SaaS A] | 10min | $25 | $300 | $900 | Free tier: 10K MAU |
| [SaaS B] | 15min | $35 | $420 | $1,260 | More features |
| [Free/OSS] | 1hr | $0 | $0 | $0 | Self-host required |
| DIY | Xhrs | $0 | ~$Y | ~$Z | + maintenance burden |

💡 **Break-even:** [When DIY becomes cheaper, if ever]
⚠️ **Hidden costs:** [Security audits, compliance, on-call burden]

9.4 Hidden Costs to Surface

Always mention relevant hidden costs:

• Security audits: $5K-50K for custom auth systems
• Compliance: SOC2, GDPR, PCI implementation time
• On-call burden: DIY = you're the support team
• Opportunity cost: Time not spent on core product
• Technical debt: Custom code needs maintenance forever

9.5 Hidden Costs to Surface

Always mention relevant hidden costs:

• Auth complexity: "DIY is 3x longer than estimated"
• Security debt: "Security issues cost $5K-50K to fix later"
• On-call burden: "You become support team 24/7"
• Compliance: "GDPR/PDPA implementation is expensive"
• Data transfer: "Cloud data egress costs add up"

Reference: See references/hidden-costs-gotchas.md for detailed gotchas.

---

Step 10: Thailand Market Context (NEW - v2.1.0)

When Thailand-specific context is detected:

Detect Thailand Context

User mentions:

• "Thailand" or "Thai"
• "PromptPay" or "2C2P"
• "TikTok Shop" or "Shopee" or "Lazada"
• Thai language in request
• Thai region/market

Provide Thai Market Recommendations

Include section:

## 🇹🇭 Thailand Market Context

### Payment Solutions (Best for Thailand)
- **PromptPay**: Zero fees, 90% adoption (TH-only)
- **2C2P**: Thailand #1 processor, installments
- **Stripe**: If expanding internationally

### Market Platforms
- **TikTok Shop**: Fastest growing (15M Thai users)
- **Shopee**: Largest (30M shoppers)
- **Lazada**: Second largest (20M shoppers)

### Compliance
- **PDPA**: Explicit consent required, data rights
- **VAT**: 7% on all Thai sales
- **Language**: Must support Thai

Reference: See references/thai-market-solutions.md for complete guide.

---

Step 11: Alternative Recommendations by Scenario (NEW - v2.1.0)

Provide multiple recommendation paths based on user priorities:

Detect User Priority

Could be:

• Speed to market
• Lowest cost
• Maximum control
• Enterprise ready
• Best for learning

Show Multiple Paths

### 🎯 Alternative Recommendations by Your Priority

**⚡ If you want: Speed to market (launch ASAP)**
→ Firebase Auth (10 min setup, free tier)
→ Cost: $0-100/month at scale

**💰 If you want: Lowest cost**
→ Firebase or Supabase (free tier never ends)
→ Cost: $0-50/month even at 100K users

**🎛️ If you want: Maximum control**
→ Supabase Auth (open source, self-hosted)
→ Cost: $100-300/month (you control everything)

**🏢 If you want: Enterprise ready**
→ Auth0 (SOC2, GDPR, compliance certified)
→ Cost: $300-1000+/month (but includes support)

**📚 If you want: Best learning experience**
→ Firebase (prototyping) + Supabase (SQL)
→ Cost: Free tier (learn before paying)

Reference: See references/alternative-scenarios.md for detailed paths.

Response Template

## 🔍 Existing Solutions Found

I found [N] existing solutions before we write custom code:

### Libraries/Packages
- **[Name]**: [one-line description] | [stars/downloads] | [link]

### Open Source Tools  
- **[Name]**: [one-line description] | [stars] | [link]

### SaaS Options
- **[Name]**: [one-line description] | [pricing] | [link]

## 📊 Build vs Buy Comparison

| Option | Type | Cost | Setup | Maintenance | Est. Tokens |
|--------|------|------|-------|-------------|-------------|
| ... | ... | ... | ... | ... | ... |

## 💰 Cost Analysis (for significant decisions)

| Option | Setup | Monthly | Year 1 | Year 3 | Notes |
|--------|-------|---------|--------|--------|-------|
| ... | ... | ... | ... | ... | ... |

💡 **Break-even:** [analysis]
⚠️ **Hidden costs:** [security, compliance, maintenance]

## 💡 Recommendation

[Clear recommendation with reasoning]

## 🔧 If You Still Want to Build

[Only if user wants custom solution - suggest hybrid approach]

Integration Plan Template (When User Accepts)

When the user says "let's use [recommended solution]" or "how do I add this?", respond with:

## 🚀 Integration Plan: [Solution Name]

### Your Project Context
- **Detected**: [framework], [package manager], [language]
- **Project structure**: [src/app/lib layout]

### Step 1: Install Dependencies

\`\`\`bash
[exact install command for their package manager]
\`\`\`

### Step 2: Configuration (if needed)

[Any config file changes needed]

### Step 3: Create New Files

📁 `[suggested/file/path.ts]`
\`\`\`typescript
[starter code matching their project style]
\`\`\`

### Step 4: Update Existing Files

📝 `[existing/file/to/modify.ts]`
\`\`\`typescript
// Add this import
import { X } from '[package]'

// Use it like this
[integration code]
\`\`\`

### ⚠️ Notes
- [Any warnings about versions, conflicts, or requirements]

### 📚 Resources
- [Official docs link]
- [Relevant examples]

Anti-Patterns to Flag

Alert users when they're about to reinvent:

• Authentication systems → "Use Auth0, Clerk, Supabase Auth"
• State management → "Consider Zustand, Redux Toolkit, Jotai"
• Form validation → "Check out Zod, Yup, React Hook Form"
• API clients → "Look at Axios, ky, ofetch"
• Date handling → "Use date-fns, dayjs, Luxon"
• CLI tools → "Consider Commander, yargs, oclif"
• PDF generation → "Use pdf-lib, jsPDF, Puppeteer"
• Email sending → "Check Resend, SendGrid, Nodemailer"
• Cron jobs → "Use node-cron, Bull, Agenda"
• Database ORMs → "Consider Prisma, Drizzle, TypeORM"

Quick Reference: Common Token Burns

Task Complexity	Typical Token Burn	Time Equivalent
Simple script (<100 LOC)	5-15K	30min-1hr
Utility module (100-500 LOC)	15-50K	2-4hrs
Feature component (500-2K LOC)	50-150K	1-2 days
Full application	150K-500K+	Days-weeks

See references/token-estimates.md for detailed breakdowns.

See references/common-solutions.md for exhaustive list of commonly reinvented wheels.

See references/integration-patterns.md for project detection and starter code patterns.

See references/pricing-data.md for SaaS pricing and cost calculation data.