> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blitzy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Greenfield Development

> Build a new product or application from scratch with a structured prompt

Organizations ship entirely new products with Blitzy that they would not have resourced otherwise. Instead of staffing a full team for months, you describe what you need — stack, architecture, features, user flows — and Blitzy generates a working codebase ready for review. Teams use this to launch internal tools, MVPs, and customer-facing products faster than traditional development allows.

<Card title="Ready to build something new?" icon="rocket" href="/templates/feature-product-development/new-product">
  Use the **New Product Template** to get started with a structured prompt
</Card>

<Note>
  **Jump to:** [When to Use](#when-to-use-this-approach) | [Prompt Structure](#prompt-structure) | [Key Considerations](#key-considerations) | [Common Patterns](#common-patterns) | [Troubleshooting](#troubleshooting)
</Note>

## When to Use This Approach

<Tabs>
  <Tab title="New Internal Tools">
    Build REST APIs, admin dashboards, internal utilities, and workflow tools that your team needs but hasn't had bandwidth to build.
  </Tab>

  <Tab title="New Customer-Facing Products">
    Launch SaaS applications, customer portals, marketplaces, and other user-facing products from a detailed product spec.
  </Tab>

  <Tab title="Proof of Concept / MVP">
    Validate ideas quickly before committing full team capacity. Ship a functional prototype to test assumptions with real users.
  </Tab>

  <Tab title="Standalone Microservices">
    Add new services to a microservices architecture with well-defined API contracts, data models, and deployment configurations.
  </Tab>
</Tabs>

## Prompt Structure

Follow the [Golden Rules](/prompt-engineering/golden-rules) when writing your greenfield prompt. Focus especially on:

* **Vision & Purpose Clarity** — Define the problem you're solving, who the users are, and what makes this product valuable
* **Stack & Architecture Decisions** — Specify tech stack, design patterns, and infrastructure choices upfront so Blitzy doesn't guess
* **Core Requirements Completeness** — List required behaviors starting with "System must..." or "Users must be able to..." to eliminate ambiguity
* **User Flow Specificity** — Describe key journeys with entry points, steps, and success criteria so generated code reflects real workflows

## Key Considerations

<CardGroup cols={2}>
  <Card title="Start with a Clear Tech Stack" icon="layer-group">
    Specify frontend framework, backend language, database, and infrastructure choices explicitly. Leaving stack decisions open leads to inconsistent or unexpected technology selections.
  </Card>

  <Card title="Define MVP Scope Ruthlessly" icon="crosshairs">
    Prioritize features into must-have vs. nice-to-have to keep the first generation focused. Trying to build everything at once produces shallow implementations across the board.
  </Card>

  <Card title="Specify Authentication & Access" icon="lock">
    User types, authentication methods, and access control rules need to be defined early. These decisions affect data models, API design, and frontend routing throughout the entire codebase.
  </Card>

  <Card title="Plan for Iteration" icon="arrows-rotate">
    The first generation is a foundation, not a finished product. Structure your prompt knowing you will extend with follow-up generations using the Add Feature workflow.
  </Card>
</CardGroup>

## Common Patterns

**Full-stack web application** — Define frontend and backend separately with clear API contracts. Specify data models, page layouts, and state management approach. Include authentication, error handling, and deployment configuration.

**API-first service** — Focus on endpoint definitions, request/response schemas, data models, and integration contracts. Specify authentication, rate limiting, and error response formats upfront.

**Internal tool / admin dashboard** — Emphasize workflows, data views, and role-based access. Define what data users need to see, what actions they can take, and how permissions map to UI elements.

## Troubleshooting

<AccordionGroup>
  <Accordion title="Generated architecture doesn't match expectations">
    Be more specific about stack choices and architectural patterns. Name the exact frameworks, libraries, and design patterns you want. Reference documentation or examples when possible.
  </Accordion>

  <Accordion title="Too many features in first generation">
    Narrow your MVP scope. Use priority tiers (must-have, nice-to-have, future) and move non-essential features to follow-up generations using the [Add Feature](/use-cases/development-modernization/add-feature) workflow.
  </Accordion>

  <Accordion title="Missing authentication or authorization">
    Add explicit auth requirements to your prompt. Specify user types, authentication method (OAuth, JWT, session-based), and access control rules for each feature area.
  </Accordion>

  <Accordion title="Generated code lacks test coverage">
    Add the [Require Test Coverage](/templates/rules/require-test-coverage) rule to your project on the platform and specify which test types (unit, integration, e2e) and coverage thresholds you expect.
  </Accordion>

  <Accordion title="Unclear how to extend after first generation">
    Use the [Add Feature](/use-cases/development-modernization/add-feature) workflow for subsequent iterations. Each follow-up generation builds on the existing codebase with scoped feature additions.
  </Accordion>
</AccordionGroup>