6 Things to Plan Before Building a Business Website With AI

Everywhere online, someone is building a website with AI in five minutes. The prompt is usually some version of “make it look like Apple, add slick animations and make it feel high-tech,” and a few moments later there’s a homepage that looks surprisingly cool.

That part is impressive, but it also hides the harder bit: a website can look ready while being completely wrong for the business behind it. If you haven’t decided what the site needs to say, how it should work, and what people are actually supposed to do there, AI will happily make those decisions for you.

We learned that while building our Unfinished app with Codex, Codex could write and revise the code, but we still had to make the important product decisions.

Quick Answer

Before asking AI to build the site, work out the main decisions first. These six short documents cover what the site needs to do, how it should work, what it should look like, how data is handled and how the build should be tested.

Before writing the first document, be honest about whether you need a website or an app. A public site explaining your services and collecting enquiries is a much smaller job than a client portal with accounts, private records and payments. Calling both of them “a website” does not give them the same technical or security requirements.

1. Decide What the Website Must Do

The product requirements document, usually called a PRD, explains why the website exists and what the first version must contain. For a normal business site, this can fit on one page.

Start with the person coming to the site and the action you want from them. Perhaps they need to request a quote, book a consultation, buy something, visit your location or understand the service well enough to call. The site can support several actions, but it still needs a clear main purpose or every page starts competing with the others.

Your PRD should cover:

• The main audience and the problem bringing them to the site
• The primary action and any useful secondary actions
• The pages and features required for the first release
• The real proof available, such as prices, photographs, qualifications, reviews or case studies
• Anything deliberately excluded from the first release
• The person responsible for approving facts, prices and final copy
• The result that will tell you whether the site is doing its job

“Make us look professional” does not tell the builder much. “A mobile visitor should understand the service, see the starting price and send a quote request without creating an account” gives you something that can be built and checked.

Write the exclusions just as clearly by stating whether the first release will take payments, create customer accounts or support several languages before the AI helpfully adds another system you never asked to maintain.

This document should also force one uncomfortable business question: do you care enough about the idea to keep working on it after the site exists? We shut down our AI-built app because the experiment had already answered our question and we did not have enough interest in turning it into a real business. AI made the product possible, but that was never the same as giving us a reason to continue.

2. Decide How It Will Be Built and Owned

The technical requirements document decides where the site lives, how people edit it and which services it depends on. Choose those things before a builder picks its favourite framework and makes every later decision more annoying.

For most business websites, the document needs to answer:

• Who owns the domain, DNS, hosting, repository and analytics accounts?
• Will the site use a managed builder, a CMS such as WordPress or Ghost, an ecommerce platform or custom code?
• Who needs to edit pages, prices, opening hours and articles without a developer?
• Which booking, CRM, email, payment, map or analytics services must connect to it?
• Which languages, currencies, countries, browsers and devices matter?
• What are the accessibility, performance and search requirements?
• How are backups, software updates, monitoring and recovery handled?
• What will the site cost each month after the initial build?

The business should own its critical accounts and give the developer or agency the access required to work. Registering the domain or production account in a contractor's personal name may feel harmless at the start, but it becomes a stupid problem when you change supplier and discover that the business does not control its own website.

Accessibility and performance also need real owners. The W3C recommends defining accessibility goals, scope and responsibilities during planning instead of adding them as a vague request before launch. The requirement does not need to demand a perfect automated score; it should name the standard, the important pages and devices, and who will test them.

Search and AI visibility are less mysterious than much of the marketing around them suggests. Google's current guidance says AI search uses the same basic foundations as Search, including clear technical structure and useful original content, and it specifically says Google does not require a special AI file or strange rewriting trick. Put crawlable pages, titles, descriptions, canonicals, sitemaps, redirects and real content in the technical plan before wasting time on an llms.txt file that does not solve any of those jobs. Google explains the current requirements here.

If the project needs several paid services, estimate them now rather than treating hosting as the only running cost. Our AI-built app cost breakdown covers the subscriptions and infrastructure that appeared after the first version already worked.

3. Map the Pages and What Happens Next

A sitemap lists the pages, while a user flow shows how someone moves through them and what happens after an important action. Even a small site needs both because visitors do not always enter through the homepage.

Give every page one job and one useful next step:

Then follow the real routes people will use. Someone arriving from Google may land directly on a service page, while somebody clicking an advert may enter through a focused offer. Neither person should have to return to the homepage to understand where they are or what to do.

Forms need more detail than “add a contact form.” Decide which fields are required, where the submission goes, who receives it, what the visitor sees afterwards, whether a confirmation email is sent and what happens if delivery fails. A form that looks complete but does nothing useful is still broken.

4. Write a Design Brief That Means Something

“Modern, clean and premium” tells AI almost nothing, so it tends to return the usual oversized headline, gradient, rounded cards and random smiling people.

Give it the real brand materials: logo files, colour values, type choices, photography, existing adverts and examples you genuinely like. Examples you dislike can be even more useful when you explain whether the problem is the colours, spacing, typography, images or the whole tone.

The brief also needs to describe mobile layouts and the repeated parts of the site, including headers, buttons, forms, cards and footers. Add the states that mock-ups often ignore, such as focus, loading, error, success and an empty result. If the site uses motion or AI-generated images, decide where they help and where they would make the business look ridiculous.

Use real or realistic copy lengths while approving the layout. A service needing 500 words should not be squeezed into three equal cards because the first mock-up looked tidy with placeholder text. Once one representative page works on desktop and mobile, approve its type, spacing, colours and components before generating the rest of the site.

5. Decide What Happens to People's Data

A static site may not need its own database, but it still needs a data plan because contact forms, analytics, booking tools and newsletters send information somewhere. For every item collected, record why you need it, where it goes, how long it stays there and who can access it.

The plan for a simple company site might confirm that there are no customer accounts or custom database, while the contact form sends a name, email address and message to the company's CRM. It should separate a normal enquiry from marketing consent, name the people allowed to read submissions and place the privacy information beside the form.

The UK's Information Commissioner's Office says privacy should be considered from the design stage and that businesses should limit personal information to what they need for a defined purpose. Its small-business guidance says people should be told why their data is collected, what happens to it, who receives it and how long it is kept. The exact law depends on where the business operates and whom it serves, but “why are we collecting this field?” is a useful question anywhere.

If users can create accounts or view private records, this document needs a proper database schema and permission matrix showing tables, relationships, ownership, user roles, administrative powers and deletion behaviour. Do not let the model infer access rules from the visible interface, because hiding an admin button or filtering a dashboard in the browser does not protect the action behind it.

OWASP's access-control guidance requires checks on a trusted service layer and recommends giving users access only to the functions and data they need. Our AI-built app security checklist goes further into testing those rules, exposed credentials, backups and account isolation.

6. Decide the Build Order and Tests

The implementation plan says what gets built first, what proves each stage works and who approves it. Without that order, an AI coding agent can redesign the header, change the database and replace half the copy while supposedly fixing one form.

A normal build can follow this order:

1. Set up the repository, business-owned accounts, and a private preview.
2. Build the common design rules and one representative page for desktop and mobile.
3. Create the approved pages with real content.
4. Connect forms, analytics, and required external services.
5. Add search metadata, accessibility work, redirects and performance fixes.
6. Test the main actions, forms, mobile layouts, browsers, permissions, backups, and failure states.
7. Approve the production version and launch with a way to restore or roll back if something breaks.

Each stage should be small enough for a person to review. Use version control from the beginning, keep production credentials out of the code, and test the real path rather than admiring the preview. Submit the form, open the email, follow the recovery link, try the site with a keyboard, and check it on an actual phone.

Let AI Draft the Documents

You do not need to write every document from an empty page. Give the model your business notes, offers, brand files, required services, and useful examples, then let it interview you and organise the answers. Remove confidential information that the chosen service should not receive.

I am planning a business website. Do not write code yet.

Ask me no more than 12 focused questions whose answers would change the site's purpose, scope, technology, design, data handling or build plan.

Then draft these six Markdown documents:

1. Product requirements
2. Technical requirements
3. Sitemap and user flows
4. Design brief
5. Data and access plan
6. Implementation plan

In each document, separate confirmed decisions, your recommendations, unresolved questions and assumptions that still need approval. Do not invent business facts, testimonials, prices, legal requirements or features. Keep the detail proportionate to the project, distinguish a public website from a web app, and include acceptance criteria that can be tested.

Finish with a list of contradictions and decisions that must be resolved before coding starts. Wait for my approval before creating an implementation prompt or changing any files.

Read the six drafts together because a platform choice in the technical requirements may conflict with an editing need, design idea or data rule somewhere else. Whenever the model recommends a feature or new field, ask why you need it and what it will cost to own after launch.

Final Verdict

Before the AI starts building, get it to map out the site and surface the decisions you still need to make. For a simple company website, that planning can stay pretty short, but if you’re dealing with accounts, payments, or private data, things like permissions, data handling, and testing need more thought. The point isn’t to create loads of documentation; it’s to work out the important stuff while it’s still easy to change, instead of discovering later that the AI quietly decided it for you.

FAQ

Do I need all six documents for a five-page website?

Yes, although each one can be short and several can live in the same file. A simple project may need only a one-page PRD, one-page technical brief, sitemap table, concise design brief, half-page data plan and implementation checklist.

What is the difference between product and technical requirements?

Product requirements explain what the website must do for the business and its visitors, while technical requirements explain how it will be hosted, edited, connected, maintained and owned.

Does a static business website need a database schema?

It does not need one if there are no accounts, custom records or first-party database, but the data and access plan should still cover forms, analytics, booking services and newsletter tools because those services may collect information outside your site.

Can an AI-generated business website rank in Google and appear in AI search?

It can, but AI does not make generic or inaccurate pages useful. Google says generated content should be checked for accuracy, quality and relevance, including titles, descriptions, structured data and image text, while its current AI-search guidance still depends on crawlable pages and useful original content.