Prompts for Building a Website: From Brief to Testing

Building a website with an AI assistant goes faster when your prompts carry the decisions already made: the technology choices, the page structure, and the behavior the team agreed on. A prompt that starts from scratch every session produces inconsistent code and repeated work. Tools like fenbs keep the approved decisions and working instructions in one place, so each new prompt picks up where the last one left off.

These templates cover the stages of a website build from requirements through to testing. Each one includes the context to fill in and a note on what a good response looks like. Adapt them to your stack and project size.

What a build prompt needs before the work starts

Website build prompts fail most often because the assistant does not know the decisions that shaped the project. Before you send a prompt to implement or review anything, check that it includes these pieces.

• Technology stack: framework, language, CSS approach, and any libraries already chosen.
• Page goal: what the visitor should do or find on this specific page.
• Approved structure: the sections or components already agreed on.
• Constraints: accessibility standards, browser support, performance targets, or style guide rules.
• Output format: a working code snippet, a plan to review first, a set of options, or a checklist.

Prompts for a requirements document

Start a website build by using an AI assistant to produce a requirements document before any code is written. This prompt turns a brief or a client conversation into a spec that the whole team can review and agree on. It catches missing decisions early, when changing them is cheap.

Write a requirements document for a website with these goals:

[describe the site and its audience]

Technology stack: [framework, language, CSS approach]
Key pages: [list the main pages]

For each page include:
- Purpose and primary user action
- Main content areas and their requirements
- Interactions or dynamic behavior needed
- Any third-party integrations (forms, payments, maps, etc.)

At the end, list the five decisions we still need to make before development starts.
Flag anywhere the specification is ambiguous.

Prompts for page structure

Once requirements are agreed, use a structure prompt to plan the component or section layout for each key page before you write code. Asking the assistant to explain the reason behind each structural choice makes it easier to evaluate and change the plan at low cost.

Plan the component structure for the [page name] page.

Framework: [e.g. React, Next.js, plain HTML]
Page goal: [what the visitor should do]
Approved requirements: [relevant parts of the requirements doc]

For each component or section:
- Name and brief description
- Props or data it needs
- Why it belongs in this position

Flag any component where the requirements are unclear.

Prompts for implementation

Use focused implementation prompts rather than asking the assistant to build an entire page at once. Smaller, specific prompts produce code you can review before it affects the rest of the project. Always include the relevant context from earlier decisions.

Build the [component or section name] for the [page name] page.

Stack: [framework, CSS approach, any relevant libraries]
Requirements: [what it needs to do]
Approved structure: [where it fits in the page layout]
Constraints: [accessibility, browser support, style guide rules]

Write the code, then list:
- Any assumption you made that I should verify
- Any decision you embedded that I should approve before this goes further

Ask the assistant to flag embedded decisions rather than letting them pass into the codebase silently. For context-specific guidance on working with AI coding tools, prompt engineering covers how to write instructions that produce consistent, reviewable results. For design-side work that feeds into the build, see prompts for website design.

Prompts for review and testing

Review prompts work best when they test code against the requirements rather than asking for general feedback. Include the original goal and any relevant constraints so the assistant can point to specific gaps, not just style preferences.

Review this code for the [component or page name].

Original requirements: [what it needs to do]
Constraints: [accessibility, browser support, performance targets]

[paste the code]

For each issue:
- Describe what is wrong
- Explain why it matters for this project
- Suggest a concrete fix

Prioritize issues that affect functionality or accessibility over style.

Keeping decisions across the build

A website build involves hundreds of small decisions: which library handles forms, why the navigation collapsed to a hamburger menu at a specific breakpoint, which colors were approved by the client. Each one is obvious at the time and forgotten within a week. When you reopen the project or bring in a new assistant, these decisions need to be recoverable from a record, not from memory.

Record the decisions that came out of each prompt as you go. The ones worth keeping are the ones that would require work to undo or that the client approved. Keep them with the project so the next implementation prompt can reference them. MCP tools, resources, and prompts explains how AI assistants can read and use an outside record like this during a build session.

A website build also accumulates technical decisions that need to be recoverable. The choice to use a specific component library, the reason a particular third-party integration was selected over an alternative, the decision to validate a form on the client rather than the server: these details are not obvious to the next developer who opens the codebase. Writing them into the project record as decisions, with the reason for each, gives any future session a usable starting point. An AI assistant that knows why a decision was made can judge whether it still applies when the project moves in a new direction, rather than treating every existing choice as open for reinterpretation.

How to do this with fenbs

1. Create a free account and add your website build as a project.
2. Write the technology decisions and approved requirements into Decisions and rules before the build starts.
3. Save the prompt templates that produced reliable output in Skills and prompts.
4. Connect your coding assistant over MCP from Integrations, so it reads the project decisions before it writes code.
5. After each review session, update the decisions with anything that changed and add new prompt variants that worked.

fenbs does not write or run code. It keeps the record the build depends on: the decisions, the approved requirements, and the prompts that produced results worth repeating. When a build session ends, the record stays current; when the next session begins, any connected assistant reads the same agreed starting point and does not have to rediscover it.