Estimation Prompts

Generate detailed project estimates for FlexBase applications — per module, per feature, with complexity classification, UI/API split, testing effort, and delivery phasing. Estimates cover the full lifecycle: extraction, code generation, code completion, UI development, unit testing, manual test case generation, and test execution.

Prerequisites

Your AI agent must have the FlexBase MCP server configured. The MCP server provides the estimation guide, conventions, and benchmarks that the agent loads automatically when processing your requests.

Guides & Conventions (Loaded Automatically by MCP)

Guide	MCP Call	Purpose
Estimation Guide	getGuideSection("estimation", ...)	Complexity tiers, hour benchmarks, templates, formulas, real project benchmarks
API Patterns Guide	getGuideSection("api", ...)	Feature operation types, handler patterns
Manual Test Case Guide	getGuideSection("manual-test-cases", ...)	Test case counts per operation type for QA estimation

What Gets Generated

• Per-module breakdown with feature-level hours, complexity tiers, subscriber counts, external dependencies

• UI estimation with or without wireframes — per page or heuristic-based

• Testing breakdown: unit test generation, manual test case generation, manual test execution (with industry benchmarks)

• Phase grouping for incremental delivery planning

• Project-level roll-up with category totals (API, UI, Testing, Infrastructure)

• Complexity classification: Simple, Medium, Complex, Very Complex per feature

• External integration estimated separately from core modules

• Output formats: Markdown (default), Excel workbook (.xlsx), or HTML report

---

Prompts — Full Project Estimation

From a BRD or Requirement Document

Analyze this BRD and generate a complete FlexBase project estimation with per-module, per-feature breakdown. For each feature, classify complexity (Simple/Medium/Complex/Very Complex), estimate FlexBase hours, identify subscribers and external dependencies. Include:
1. API estimation per module with feature-level hours
2. UI estimation (note: wireframes not available — use heuristic)
3. Unit test estimation (features × 0.4 hrs)
4. Manual test case generation (modules × 1.5 hrs)
5. Manual test execution estimate based on test case counts
6. Extraction + code generation phase
7. Project-level roll-up with totals and delivery phases

@[BRD_FILE].md

Analyze this BRD and produce a detailed estimation. Identify which modules are Simple (CRUD, 0 subscribers), Medium (1-2 validations), Complex (3+ subscribers, external deps), or Very Complex (state machine, background jobs). Output a per-module table with feature count, API hours, UI hours, test hours, and total hours.

@[BRD_FILE].md

From FlexBase Extraction JSON/Markdown

Parse this FlexBase extraction and generate a project estimation. For each module, use the feature list and domain service attributes to estimate hours. Count subscribers from events, identify external dependencies from subscriber names. Apply FlexBase hour benchmarks: GETLIST=0.5-1h, CREATE(simple)=1.5-2h, CREATE(complex)=5-14h, UPDATE(simple)=1-1.5h, UPDATE(complex)=4-28h, DELETE=0.5-1h.

@[PROJECT]_Import.json

Parse this extraction Markdown and produce a per-module estimation with:
- Feature-level breakdown (operation type, complexity, hours, subscribers)
- Module-level summary (total hours, complexity tier, key drivers)
- Testing estimate (unit tests + manual test cases + execution)
- Phase grouping for delivery planning

@[PROJECT]_Summary.md

From Legacy Application Analysis

Analyze this legacy application output and estimate the FlexBase migration. For each legacy module:
1. Map legacy features → FlexBase operation types (CREATE, UPDATE, DELETE, GET, GETPAGEDLIST)
2. Identify triggers/procedures → subscriber effort
3. Estimate data migration verification time
4. Identify external system integrations and estimate separately
5. Flag features that increase complexity (state machines, batch jobs, complex reports)

@[LEGACY_ANALYSIS_FILE].md

---

Prompts — API-Only Estimation

Full API Estimation

Generate an API-only estimation for this project. For each module, provide:
1. Feature list with operation type and complexity tier
2. Subscriber count and per-subscriber hour estimate
3. External dependency identification and integration hours
4. Module total in hours and days (at 7 hrs/day)
5. Overall API development total with phase grouping

@[REQUIREMENTS_FILE].md

Single Module API Estimation

Estimate the [ModuleName] module API development. It has these features:
[List features with operation types]

For each feature, classify complexity and estimate hours. Identify:
- Which features have subscribers (and how many)
- Which features call external systems
- Whether a state machine is involved
- Background/cron job requirements

Output a feature-level table with hours and a module total.

---

Prompts — UI Estimation

With Wireframes

Analyze these wireframes/mockups and estimate UI development for each page/component. Classify each page as Low (1-3h), Medium (4-7h), High (8-14h), or Very High (14-20h+) complexity. Include:
1. Per-page hours with complexity justification
2. UI infrastructure (one-time): scaffold, theme, REST client, shared components
3. Responsive considerations (if applicable)
4. Which API modules each page depends on
5. UI total hours

@[WIREFRAMES_OR_MOCKUPS].md

Without Wireframes (Heuristic)

Generate a UI estimation based on these API modules (no wireframes available). For each module, estimate the admin pages needed using the heuristic:
- Simple module → 1 list/detail page (3-6 hrs)
- Standard entity → 1 list + 1 detail page (8-15 hrs)
- Transactional → 2-3 pages + 1 dialog (15-35 hrs)
- Complex transactional → 3-5 pages + 2 dialogs (30-60 hrs)
- Dashboard/Reports → 1-2 pages (6-14 hrs)

Do NOT bake contingency into per-page hours. Instead, show straight hours and note a recommended contingency % as a separate line item (e.g., +10% with wireframes, +20% without wireframes, +30% for vague requirements). Note which pages would benefit most from wireframe clarity.

Modules: [List modules with complexity tiers]

Public + Admin UI Combined

Estimate the full UI for this project including:
1. Public-facing pages (CMS content + hybrid CMS/API + booking flows)
2. Admin pages (per API module using the module-to-page heuristic)
3. UI infrastructure (one-time setup)
4. Shared component library
5. Per-page breakdown with complexity and hours

Note which pages have wireframes and which use the heuristic estimate.

@[BRD_OR_REQUIREMENTS].md

Separate UI Estimation (Standalone)

Generate a standalone UI estimation document separate from the API estimation. Organize by:
1. Public pages (grouped by section: CMS, Hybrid, Booking/Account)
2. Admin pages (grouped by module)
3. UI infrastructure (one-time)
4. Per-page: name, route, complexity, hours, API dependencies, notes
5. Total with recommended contingency shown as a separate line item (not baked in)

If wireframes are not available for certain pages, mark them with "⚠️ No wireframe — heuristic estimate" and list what wireframe information would reduce the estimate. Show a recommended contingency % as a separate line, not baked into page hours.

@[BRD_OR_REQUIREMENTS].md

---

Prompts — Testing Estimation

Unit Test Estimation

Estimate unit test effort for this project. For each module:
- Count features by operation type
- Apply: CREATE=0.5-0.75h, UPDATE=0.35-0.6h, DELETE=0.25-0.4h, GETBYID=0.15-0.25h, GETPAGEDLIST=0.25-0.4h per feature
- Calculate module subtotal and project total
- Note: AI generates tests, developer reviews/refines (~8-12% of dev time)

@[PROJECT_EXTRACTION_OR_BRD].md

Manual Test Case + Execution Estimation

Estimate manual QA effort for this project:
1. Test case generation: modules × 1.5 hrs (AI-generated, developer-reviewed)
2. Test case count estimate using FlexBase minimums: CREATE=14, UPDATE=10, DELETE=7, GETBYID=6, GETPAGEDLIST=9
3. Test execution (first pass): P0 × 0.4h + P1 × 0.25h + P2 × 0.15h + P3 × 0.1h
4. Regression cycles: first pass × 0.6 (×2 cycles)
5. Defect retest: total cases × 12% defect rate × 0.25h per defect
6. Total QA effort in hours and days

@[PROJECT_EXTRACTION_OR_BRD].md

Combined Testing Estimation

Generate a combined testing estimation for this project covering all testing activities:
1. Unit test generation and refinement (per module)
2. Manual test case generation (per module)
3. Manual test case execution — first pass (per module, by priority)
4. Regression cycles (2 cycles at 60% of first pass)
5. Defect discovery and retest
6. Test infrastructure setup (test data, environments)
7. Testing total as percentage of development effort
8. Industry benchmark comparison

@[PROJECT_EXTRACTION_OR_BRD].md

---

Prompts — Module-by-Module Estimation

Individual Module Estimation

Estimate the [ModuleName] module completely:

**API Estimation:**
- Features: [list features with operation types]
- Subscribers: [list or count]
- External deps: [list or "None"]
- State machine: [Yes/No, how many states]

**UI Estimation:**
- Wireframes available: [Yes/No]
- If yes: [describe pages/mockups]
- If no: use heuristic based on module complexity

**Testing Estimation:**
- Unit tests: per-feature calculation
- Manual test cases: count estimate with priority distribution
- Test execution: first pass + regression

Output the complete module estimate in the per-module template format.

Batch Module Estimation (Multiple Modules)

Estimate these modules and provide a comparison table:

Module 1: [Name] — [brief description]
Module 2: [Name] — [brief description]
Module 3: [Name] — [brief description]
...

For each module, output:
| Module | Complexity | Features | API Hrs | UI Hrs | Unit Test | TC Gen | TC Exec | Total |

Then provide the project roll-up total.

@[REQUIREMENTS_FILE].md

---

Prompts — Estimation Outputs

Excel Workbook

Generate a Node.js ExcelJS script that produces a professional estimation workbook (.xlsx) for this project with:
1. Effort Breakdown sheet — all modules with #, Item, Route/Scope, Category, Complexity, UI Hrs, API Hrs, Total Hrs, Total Days, Notes
2. Per-phase section headers with color coding
3. Testing section with unit test + manual test breakdowns
4. Summary section with KPIs (total hours, days, weeks, team size)
5. Frozen headers, auto-filters, zebra striping
6. Complexity colors: Simple=green, Medium=amber, Complex=red, Very Complex=purple

@[PROJECT_ESTIMATION].md

HTML Report

Generate an HTML estimation report for executive presentation with:
1. Project overview header with key metrics
2. Visual phase timeline (horizontal bar chart)
3. Module comparison table with complexity badges
4. FlexBase vs Traditional comparison callout
5. Cost projection section (configurable hourly rates)
6. Testing effort breakdown
7. Risk factors and open questions with hour impact
8. Professional styling with responsive layout

@[PROJECT_ESTIMATION].md

Markdown Document

Generate a comprehensive estimation markdown document for this project with:
1. Executive summary (total hours, weeks, key metrics)
2. Methodology section (FlexBase approach, assumptions, 7h/day)
3. Per-module tables with feature-level breakdown
4. UI estimation (with wireframe availability noted per page)
5. Testing matrix (unit + manual + execution)
6. Phase delivery plan
7. External integration summary
8. Risk register with mitigation and hour impact
9. Open questions requiring stakeholder decisions

@[BRD_OR_EXTRACTION].md

---

Prompts — Comparison & Analysis

FlexBase vs Traditional Estimation

Produce a side-by-side comparison of FlexBase AI-assisted vs Traditional team development for this project:
- FlexBase: 1 dev + AI, 7h/day, 67% generated code, day-1 infrastructure
- Traditional: 6-10 person team, 8h/day, phase-gated, build infrastructure from scratch
- Compare: timeline (weeks), effort (person-days), cost (configurable rates)
- Show what FlexBase provides day-1 that traditional must build (CQRS, events, caching, audit, etc.)

@[BRD_OR_EXTRACTION].md

Gap Analysis (Estimate vs Actual)

Compare this project's original estimate against actual hours spent. For each module:
- Estimated hours vs Actual hours
- Variance (% over/under)
- Root cause for significant variances
- Lessons learned for future estimation accuracy

Estimated: @[ORIGINAL_ESTIMATE].md
Actual: @[TIMESHEET_OR_ACTUAL].md

---

Examples

Project	Modules	API Hours	UI Hours	Total	Location
SSW (Sri Sri Wellbeing)	25	~288 hrs	~370 hrs	~700 hrs	Samples/Welbeing/Analysis/
KG (KaalGyan Calendar)	13	~180 hrs	TBD	~180+ hrs	Samples/KG/
SSW Estimation v6 (Excel)	25	—	—	—	Samples/Welbeing/Analysis/generate-module-estimates-v6.js
SSW Estimation v8 (HTML)	25	—	—	—	Samples/Welbeing/Analysis/SSW-RFP-Detailed-Estimation-v8.html