Claude Prompts for SaaS: The 4-Stage Build Workflow From Idea to Production Code

Four copy-paste prompts that walk Claude through building a full SaaS or full-stack app from idea to production code. Each prompt builds on the output of the one before it. You describe the product once. Claude handles architecture, file structure, ticket breakdown, and code.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

Why four prompts instead of one

Each stage gives Claude the context the next stage needs

The biggest mistake when building with Claude is asking it to write code before it understands what you're building. You get something that runs but doesn't match your requirements. You spend more time correcting than building.

This four-stage workflow fixes that by separating thinking from building.

Stage 1: MasterPlan. Claude interviews you about your SaaS, understands the product at a conceptual level, and produces a masterplan.md file. This is the blueprint everything else is built from. No code written.

Stage 2: Framework. Claude reads the masterplan and scaffolds the entire project structure. Empty files, folder hierarchy, placeholder comments. Still no real code. Just the skeleton.

Stage 2.5: Low-Level Planner. Claude reads the masterplan and breaks it down into detailed implementation tickets with acceptance criteria, technical requirements, and risk assessments. Your task board before development starts.

Stage 3: Development. Claude reads the masterplan, the framework, and the tickets, then writes production-quality code for each component.

Each stage's output becomes the next stage's input. The earlier stages prevent the later stages from going off-track.

What you build with these prompts

Any SaaS, full-stack app, or client-facing tool

The prompts work for any web application or SaaS product. For GTM engineers and agency owners, the most common use cases:

• A client-facing reporting dashboard that pulls campaign data and generates weekly reports
• A lead enrichment tool that runs your Clay waterfall via a simple UI
• An internal outreach brief builder that your team uses to onboard new clients
• A SaaS product that productises your agency's core service
• A prospect research portal that your setters use to prep for DM conversations
• A sequence management tool for managing multiple client campaigns in one place

The prompts don't care what you're building. They work because they force Claude to understand your specific product before touching code.

How the output files connect

Three files Claude produces and reads across the four stages

masterplan.md (output of Stage 1, input to everything else): project overview, target audience, core features, tech stack recommendations, data model, UI principles, security considerations, development phases, and potential challenges.

Project_Structure.md (output of Stage 2, input to Stage 3): the complete file and folder hierarchy with a comment in each file describing its purpose.

Implementation_Steps.md (output of Stage 2.5, input to Stage 3): the ticket backlog. Each ticket has a title, description, acceptance criteria, technical requirements, dependencies, complexity estimate, implementation approach, and testing requirements.

Stage 3 reads all three. Claude knows the big picture from the masterplan, knows the structure from the project files, and knows what to build next from the tickets. This is why Stage 3 produces better code than asking Claude to build directly.

Stage 1 turns your product idea into a structured technical blueprint without writing a line of code. Paste this prompt into a new Claude conversation. Claude will interview you about your SaaS one question at a time and produce a masterplan.md file that every subsequent stage reads.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

What the MasterPlan prompt does

An experienced architect interviews you and produces a blueprint

The prompt turns Claude into a software architect who asks you questions about your SaaS one at a time. It covers everything: what you're building, who it's for, what platforms it runs on, how data is stored, what third-party tools it needs, and what the biggest risks are.

The output is masterplan.md, a structured document covering: project overview and objectives, target audience, core features and functionality, tech stack recommendations, conceptual data model, UI design principles, security considerations, development phases and milestones, potential challenges and proposed solutions, and future expansion possibilities.

No code is generated during this stage. The entire session is conceptual planning.

For GTM engineers: describe your tool in plain English. You don't need to know what tech stack to use or how authentication should work. The prompt asks about those things and offers options with pros and cons before making a recommendation.

The MasterPlan prompt

Copy and paste this as a new Claude Project system prompt or as the first message in a new conversation

You are an experienced and friendly software architect and software engineer. Your goal is to help me understand and plan my project through a collaborative conversation.

Follow these steps:

1. Introduce yourself. Explain that you will guide me through a series of questions to understand the project at a high level, and that you will create a masterplan.md document as a blueprint once you have enough information.

2. Ask questions one at a time in a conversational way. Use my previous answers to inform your next questions.

3. Focus 70% of the conversation on understanding what I am building: the purpose, the problem it solves, who uses it, what they do in it, and why it matters.

4. Focus 30% on guidance: when technical topics come up (choosing a database, auth approach, hosting), offer two or three options with brief pros and cons, give your recommendation, and explain your reasoning without jargon.

5. Proactively ask about things I may not have considered: scalability, security, third-party dependencies, edge cases, potential competitors.

6. Ask if I have wireframes, sketches, or diagrams to describe or share.

7. Cover all of the following before producing the masterplan:
- Core features and functionality
- Target audience and user types
- Platform (web, mobile, desktop)
- UI and UX approach
- Data storage and management
- User authentication and security requirements
- Third-party integrations
- Scalability requirements
- Potential technical risks

8. Once you have enough information, tell me you are going to produce masterplan.md. Then generate the file with these sections:
- Project Overview and Objectives
- Target Audience
- Core Features and Functionality
- High-Level Tech Stack Recommendations
- Conceptual Data Model
- User Interface Design Principles
- Security Considerations
- Development Phases and Milestones
- Potential Challenges and Proposed Solutions
- Future Expansion Possibilities

9. After producing it, ask me for feedback and revise based on my input.

10. Do not generate any code during this conversation. Focus entirely on planning and architecture.

Begin by introducing yourself and asking me to describe what I want to build.

How to get a better masterplan

Tips for the interview stage

Describe the problem before the solution. Instead of "I want to build a lead enrichment tool," say "I want to solve the problem of manually building prospect lists for clients. Right now I'm doing it in Clay and it takes 2 hours per client per week." Claude's questions will be more targeted when it understands the pain first.

Answer the questions, then stop. The prompt asks one question at a time. Answer it and wait for the next. Don't try to pre-answer everything upfront. The back-and-forth is what makes the masterplan accurate.

Be honest about what you don't know. If Claude asks about your preferred database and you have no preference, say so. It will give you a recommendation with reasoning. That recommendation goes into the masterplan and the rest of the stages build on it.

Review before accepting. When Claude produces masterplan.md, read every section before saying it looks good. The development phase prompt, framework prompt, and ticket prompt all read from this file. Errors in the masterplan become errors in the code.

Save the file. Download the masterplan.md output and save it in your project folder. Stage 2 reads from this file.

Stage 2 takes masterplan.md and scaffolds the entire project. Every folder, every file, every key component gets created with a placeholder comment and TODO markers. No real logic. Just the skeleton that Stage 3 fills in. Paste this prompt into Claude along with your masterplan.md content.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

What the framework prompt does

Claude reads the blueprint and builds the project skeleton

The framework prompt tells Claude to read masterplan.md and create the full project file structure. Every file it creates follows a specific pattern:

• A brief comment at the top explaining what the file does
• The full file path as a comment to prevent naming conflicts
• Placeholder import statements for likely dependencies
• Empty class or function templates for core functions
• TODO comments where the actual logic will go

The output is a Project_Structure.md file documenting every directory and file, plus the actual files themselves. Stage 3 reads Project_Structure.md to know what to build and in what order.

No detailed code is written at this stage. The constraint is deliberate: a complete skeleton is faster to correct than half-written code.

The Framework Creation prompt

Paste this into Claude with your masterplan.md content attached or pasted below it

You are moving to Stage 2 of the development process. Your goal is to create an initial project framework based on the masterplan.md file.

Follow these steps:

1. Read and analyse the masterplan.md content thoroughly. Understand the app's overall design, main features, and architecture.

2. Build a high-level project layout with the necessary directories representing the architecture (frontend, backend, database) and key functionalities.

3. For each essential component or feature in the masterplan, create a foundational file with minimal content:
   - A brief comment at the top explaining the file's purpose
   - A comment with the full file path to avoid naming conflicts
   - Placeholder import statements for likely dependencies
   - Empty class or function templates for core functionality
   - TODO comments indicating where major logic will be implemented

4. For the frontend (if applicable):
   - Create basic component files with initial templates
   - Set up placeholders for main pages or views
   - Provide initial routing setup

5. For the backend (if applicable):
   - Create files for main API endpoints or services
   - Draft initial model files following the data model in the masterplan
   - Set up a preliminary database connection file

6. Documentation and configuration:
   - Create a README.md with project title, brief description, and placeholder sections for setup instructions, features, and tech stack
   - Generate configuration files (package.json, .gitignore) with only the essential details
   - Create a Project_Structure.md that lists every file and directory created, with a one-line description of each

7. After creating everything, provide a summary of the files and directories created and what each major component does.

8. Keep all files minimal. Just enough to indicate purpose and place in the structure. No actual logic or detailed code.

9. Confirm you are ready to begin and ask if I want to proceed.

Here is the masterplan.md content:
[PASTE YOUR MASTERPLAN.MD CONTENT HERE]

What to check after Stage 2

Review before moving to tickets or development

Check the folder structure makes sense. Does the directory hierarchy match how you described the app? Is the frontend separated from the backend? Are utility files in the right place?

Check that all core features have corresponding files. Open masterplan.md, look at the core features section, and verify each one has at least one file representing it in the framework.

Check the TODO comments. Claude should have added TODO markers in every file showing where real logic goes. If a file is empty without TODOs, ask Claude to add them before moving on.

Save Project_Structure.md. This file is read by Stage 3. Save it in the root of the project alongside masterplan.md.

❌ Don't ask Claude to start filling in the code yet. That's Stage 3's job. If Claude starts writing real logic in Stage 2, tell it to stop and replace the code with TODOs.

The Low-Level Planner sits between the framework and development. It reads masterplan.md and breaks it down into detailed implementation tickets. Each ticket has a title, description, acceptance criteria, technical requirements, complexity estimate, and risk assessment. This becomes your task board for Stage 3.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

What the Low-Level Planner does

Masterplan in. Ticket backlog out.

The planner prompt turns Claude into a Technical Solutions Architect who reads your masterplan and produces a structured ticket for every feature and component. For each ticket it creates:

• A clear title and detailed description
• Specific, measurable acceptance criteria
• Technical requirements (architecture components, APIs, data models, security, performance)
• Dependencies on other tickets
• Complexity estimate (S, M, L, XL)
• A suggested implementation approach
• Testing requirements
• A list of additional information needed before building
• Risk assessment with mitigation strategies

The output is Implementation_Steps.md. Stage 3 reads this to know what to build and in what order. Running Stage 3 without this file means Claude has to infer the implementation order itself, which produces less structured code.

The Low-Level Planner prompt

Paste this into Claude with your masterplan.md content

You are an experienced Technical Solutions Architect and Project Manager. Your goal is to analyse my masterplan.md and create detailed implementation tickets through a collaborative process.

Follow these steps:

1. Read and analyse the masterplan.md content thoroughly. Identify all core components, features, and technical requirements. Create a high-level system architecture overview.

2. Break down each feature and component into specific, actionable implementation tasks. Organise tasks into logical groups based on dependencies and priority. Apply SOLID principles and consider scalability.

3. For each task, create a ticket in this format:

## [Ticket ID] - [Title]

### Description
[What needs to be built and why]

### Acceptance Criteria
- [Specific measurable condition 1]
- [Specific measurable condition 2]

### Technical Requirements
- Architecture components involved
- Required APIs or integrations
- Data models and relationships
- Security considerations
- Performance requirements

### Dependencies
- [Other tickets this depends on]

### Complexity
[S / M / L / XL]

### Implementation Approach
[How to build this, step by step]

### Testing Requirements
- [What needs to be tested and how]

### Additional Information Needed
- [What is unclear or missing]

### Risk Assessment
- [Risk]: [Mitigation strategy]

4. After creating all tickets, ask me for feedback. Identify any gaps in the technical information and ask focused questions about non-functional requirements, integration details, performance expectations, and security constraints.

5. Organise the tickets into a logical build order and save the full output as Implementation_Steps.md.

Here is the masterplan.md content:
[PASTE YOUR MASTERPLAN.MD CONTENT HERE]

How to use the ticket output in Stage 3

Reference tickets in your development prompts for sharper code

When you start Stage 3, reference specific ticket IDs rather than asking Claude to implement everything at once:

Implement ticket TICKET-03 from Implementation_Steps.md. Read the acceptance criteria and technical requirements before starting. Stop when the acceptance criteria are met.

This forces Claude to read the acceptance criteria before writing code and to verify its output against them before moving on. The resulting code is more targeted and easier to test.

For large SaaS builds: work through tickets in dependency order. The Low-Level Planner organises them by dependencies, so start at the top of Implementation_Steps.md and work down.

✅ Review the tickets before Stage 3. If a ticket's acceptance criteria are vague, sharpen them now. The development phase uses them as a definition of done.

Stage 3 is where the code gets written. Claude reads masterplan.md, Project_Structure.md, and Implementation_Steps.md and implements each component to production-grade standards. This prompt governs the entire development phase.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

What the Development prompt does

Production-grade code from the three planning documents

The development prompt tells Claude to write real code that meets senior developer standards. It reads from all three previous outputs and implements features in the order defined by the tickets.

The standards it enforces:

• Clean, organised, and easy to understand
• Comments on complex logic and important design choices
• Core functionality implemented first
• Basic error handling and input validation where needed
• After each major component, a summary of what was built and why the key decisions were made

What it doesn't enforce (by design): extensive testing, advanced performance optimisations, or security measures beyond what the masterplan specifies. This keeps sessions focused on shipping core functionality.

The Development Phase prompt

Paste this into Claude at the start of each development session along with your three planning documents

You are now in Stage 3 of the app development process. Your goal is to transform the project framework into complete, production-quality code.

Before writing any code:
1. Read masterplan.md for the overall design and requirements
2. Read Project_Structure.md to understand the complete file structure
3. Read Implementation_Steps.md to see the full ticket backlog and understand where we are in development based on my input

Then follow these standards for all code:

- Write production-grade code to the standard of a senior developer
- Keep code clean, organised, and easy to understand
- Add comments to clarify complex logic or important design decisions
- Implement core functionality first
- Include basic error handling and input validation
- For third-party services and APIs mentioned in the masterplan, implement them using your best judgment
- Choose the most suitable methods for database operations based on the project requirements
- Avoid writing extensive tests unless I specifically ask for them
- Do not prioritise performance optimisations unless they are critical for core functionality
- Implement security measures only when explicitly required in the masterplan

After completing each major component or feature:
- Provide a concise summary of what was implemented
- Explain any significant design decisions or assumptions
- Highlight any areas where you had to interpret the requirements
- Ask if I want to review any part of the code before continuing

When you finish:
- Give an overview of all features implemented
- Describe any challenges and how they were resolved
- Suggest next steps or areas for further refinement
- Ask for my feedback

If anything is unclear or missing, ask before implementing.

Confirm you are ready and ask which ticket or component I want to start with.

[PASTE YOUR MASTERPLAN.MD CONTENT HERE]

[PASTE YOUR PROJECT_STRUCTURE.MD CONTENT HERE]

[PASTE YOUR IMPLEMENTATION_STEPS.MD CONTENT HERE]

How to run Stage 3 effectively

Work ticket by ticket, not feature by feature

Start with the first ticket in dependency order. Ask Claude to implement Ticket 1 from Implementation_Steps.md. Wait until it confirms the acceptance criteria are met before moving to Ticket 2.

Start with Ticket 1 from Implementation_Steps.md. Implement it to the acceptance criteria listed in the ticket. Show me a summary when it is done.

Review after each ticket. Don't let Claude run through the entire backlog unattended on the first session. Review each ticket's output, run it if possible, and confirm it works before proceeding.

Save solutions to CLAUDE.md. When Claude solves a problem that's likely to recur (a database connection pattern, an auth flow, an API response format), ask it to save the solution to CLAUDE.md. Future sessions load this automatically.

Save the solution to this to CLAUDE.md so you always apply this approach going forward.

Use the same context across sessions. If you start a new Claude session mid-development, paste the development phase prompt again along with the three planning documents. Claude re-reads the context and picks up from wherever Implementation_Steps.md shows as done.

❌ Don't ask Claude to implement everything at once in a single message. Ticket by ticket gives you checkpoints to catch errors before they compound.

When Claude makes assumptions

The development prompt tells Claude to document its assumptions after each component. Read these. If an assumption doesn't match your intent, correct it immediately before moving to the next ticket. Unaddressed assumptions compound into hard-to-trace bugs by the time you reach later features.

The prompt also tells Claude to ask clarifying questions when requirements are unclear. Answer them before Claude implements. "Proceed with your best guess" leads to code that needs rewriting.

How the four prompts work in practice, using an outbound reporting dashboard as a concrete GTM example. Each stage shown with what Claude produces and what you review before moving on.

Source: github.com/avijeett007/Develop-With-AI-Beginners-Guide by avijeett007

The worked example: a client outbound reporting dashboard

Turning "I want a dashboard for my clients" into production code

The tool: a web dashboard where GTM agency clients log in, see their live campaign metrics (sends, open rate, reply rate, positive replies, meetings booked), and download a weekly PDF report. The agency's operators update the data; clients read it.

This is a realistic tool for a GTM agency to build for client retention. It takes the manual weekly report process and replaces it with a self-serve portal.

Stage 1 in practice: the MasterPlan interview

What the interview looks like and what masterplan.md contains at the end

What you tell Claude: "I want to build a reporting dashboard. My GTM agency manages outbound campaigns for 15 clients. Right now I send them a manual email every week with their stats. I want to build a portal where they can log in and see their numbers."

Questions Claude asks: How are you currently tracking the campaign data? (Answer: CSV exports from Instantly.) Should clients be able to see historical data or just current week? What metrics matter most to them? Do you want the PDF export automatically or on-demand? Should operators have a different view from clients?

What masterplan.md contains after the interview:

• Two user types: client (read-only) and operator (read/write)
• Core features: client login, metrics dashboard, historical trend charts, weekly PDF export, operator data upload via CSV
• Tech stack recommendation: Next.js frontend, Node.js API, PostgreSQL database, Auth.js for authentication, Vercel for hosting
• Data model: clients table, campaigns table, weekly_metrics table
• Security: client can only see their own data, operator can see all clients
• Development phases: auth first, data model second, dashboard third, PDF export fourth

Stage 2 in practice: the project framework

What the scaffolded project looks like

Claude produces a folder structure matching the masterplan:

reporting-dashboard/
  frontend/
    components/
      MetricsCard.tsx        // Displays a single campaign metric
      ClientDashboard.tsx    // Main dashboard view for client users
      OperatorView.tsx       // Operator data management interface
      PDFExportButton.tsx    // Triggers PDF generation and download
    pages/
      index.tsx              // Login page
      dashboard.tsx          // Client dashboard route
      operator.tsx           // Operator management route
    lib/
      auth.ts                // Auth.js configuration
      api-client.ts          // Frontend API request helpers
  backend/
    routes/
      auth.ts                // Login and session management endpoints
      metrics.ts             // Campaign metrics read endpoints
      upload.ts              // CSV upload endpoint for operators
      export.ts              // PDF export generation endpoint
    models/
      client.ts              // Client data model
      campaign.ts            // Campaign data model
      metrics.ts             // Weekly metrics data model
    db/
      connection.ts          // PostgreSQL connection setup
      migrations/            // Database schema migrations
  package.json
  .gitignore
  README.md
  Project_Structure.md

Every file contains a brief purpose comment and TODO markers. No real code yet.

Stage 2.5 in practice: the ticket breakdown

A sample ticket from Implementation_Steps.md

## TICKET-01 - Database Schema and Initial Migration

### Description
Create the PostgreSQL database schema for the three core tables: clients, campaigns, and weekly_metrics. Set up the initial migration file.

### Acceptance Criteria
- clients table exists with: id, name, email, created_at
- campaigns table exists with: id, client_id, name, platform, status, created_at
- weekly_metrics table exists with: id, campaign_id, week_start, sends, open_rate, reply_rate, positive_replies, meetings_booked
- Foreign key from campaigns.client_id to clients.id
- Foreign key from weekly_metrics.campaign_id to campaigns.id
- Migration runs without errors on a fresh database

### Complexity
S

### Dependencies
None

### Implementation Approach
Create a migration file using the project's database library. Define all three tables in dependency order (clients first, then campaigns, then metrics).

### Risk Assessment
- Risk: Schema changes after data exists require migrations
  Mitigation: Keep the schema minimal at this stage. Extension is easier than correction.

Stage 3 in practice: first development session

What happens when you paste the development prompt and start with Ticket 1

You paste the development prompt with all three planning documents attached. Claude confirms it has read them and asks which ticket to start with.

You say: "Start with Ticket 1."

Claude reads the acceptance criteria for TICKET-01, creates the database connection file in backend/db/connection.ts, writes the migration file with all three tables and their foreign keys, and then produces a summary:

"Implemented the database schema with clients, campaigns, and weekly_metrics tables. All foreign keys are in place. I assumed PostgreSQL 14 based on the masterplan. The migration uses raw SQL for maximum compatibility. Ready for Ticket 2 (authentication setup) or I can first show you the migration file for review."

You review the migration file. It matches the acceptance criteria. You say: "Move to Ticket 2."

This is the cadence for the entire development phase. Ticket by ticket, review at each checkpoint, and the planning documents keep Claude on track across sessions.