Build a Next.js Website With an AI Agent

The agent builds better from evidence than from taste. Before the first prompt, confirm three inputs exist:

• Screenshots of about ten relevant sites, on desktop and mobile. A desktop capture alone hides collapsed menus, reordered sections and mobile-only problems.
• A section plan with a locked order for both layouts, following the visitor's questions: what is this, is it for me, why trust it, what do I do next.
• A rough mock-up - an AI-generated image is enough to set hierarchy and rhythm; use Figma when screens, states or approvals need exact detail.

From the screenshots, note which sections most sites share, which only a few have, and what nobody explains well. The shared ones are what visitors expect; the gaps are where your site can be clearer. This is evidence, not a copying exercise.

Write down what in the mock-up is intentional. The agent cannot tell a firm spacing rule from an accident of the image generator.

An empty repository still starts from a template: the official create-next-app starter or your own approved one. Commit that clean baseline before the agent changes anything. Confirm the package manager, TypeScript, linting, App Router, folder structure, environment variable rules, and the commands that prove the project works.

Keep an AGENTS.md file at the repository root. Current Next.js releases point coding agents to the documentation bundled with the installed version. Add your own source-of-truth order, commands, design rules, stop conditions and acceptance checks outside any block the framework manages.

Ask the agent to run the site and look at the rendered page after every meaningful edit. Code that compiles is not enough when the browser shows a broken route, a console warning, an overflow or a missing state.

Next.js explains the current agent setup and runtime loop.

Start the visible build with the shared frame. The header sets navigation, language behaviour and the main action. The footer carries repeated navigation, brand, legal and contact information.

Build both from reusable Skills, so their rules and checks outlive this project. Feed them the current brand files, approved routes, language labels and legal links. The Skill defines the repeatable behaviour; the project files supply the values.

Build one section at a time, in the approved order. For each, give the agent the content, the reference screenshot, the required behaviour, responsive notes and acceptance checks.

Reuse Skills and components from earlier builds when they genuinely fit, instead of pasting copies between projects. A reusable section takes content and style as inputs and keeps its accessibility and responsive rules intact.

Review each section inside the page, not only on its own. The next section often exposes weak spacing, a repeated message or an abrupt visual change that a component preview hid.

A language selector is not finished when its menu opens. Each option must lead to the right route and render that language's content. Navigation labels, buttons, forms, metadata, error messages and the page's lang attribute must all agree.

Keep translations in one content source or dictionary, not scattered through components. In the App Router, locale routing is yours to set up: a [lang] route segment plus a Proxy that sends visitors to the right sub-path or domain. The framework gives you the mechanism; the locale model and the translated content are still your job.

Test switching from more than the homepage. Refresh, follow internal links, submit a form and open a missing route. The visitor should never land silently in the wrong language.

Next.js documents internationalised routing and rendering.

A contact or lead form does not justify a database on its own. First decide where a submission goes, what validation it needs, what the visitor sees after sending, and who answers it.

Next.js handles form submissions with Server Actions. Validate input on the server, and treat authentication and authorisation as server-side checks, never as properties of the visible form.

Add a database when the site must keep structured data, support accounts, run a content workflow or query stored records. n-g.be uses Supabase where it needs stored data; that is a project choice, not a requirement for every Next.js website.

Next.js shows how forms work with Server Actions.

Run two focused reviews before calling the first pass done. First, check every meaningful image and write alt text that says what it is for in context. Decorative images get empty alt text so screen readers skip them.

Second, compare the whole interface with the approved colour tokens. Replace near matches, one-off shades and framework defaults. Check text, links, focus states, buttons, form feedback, icons and the mobile menu.

Both passes work better once the page exists. The agent compares one finished interface instead of trying to hold a rule across many separate section prompts.

Create a named second-pass queue, and keep these tasks out of the first build until routes, content, languages and core actions work:

• final images and responsive crops
• page-specific Open Graph images and metadata
• internal links and campaign tracking links
• mobile speed and image loading
• animations that improve understanding or feedback

Next.js has file conventions for metadata and Open Graph images, plus built-in image and font optimisation. They make the work faster; each page still needs correct content and a human check.

Review the current metadata and OG image conventions.

When a website grows several related tools, keep them in one repository with shared components, tokens, types and utilities. Deploy each tool separately when it needs its own runtime, domain or release cycle.

A shared header, validation rule or design token then changes once and reaches every tool after review, instead of being copied and fixed repository by repository.

Vercel supports several projects connected to one repository, each with its own root directory and deployment. Other hosts differ, so check your platform's monorepo rules before fixing the structure.

Vercel documents the multi-project monorepo pattern.

Run lint and a production build, then review the real site on desktop and mobile. Click every important route, switch every language, submit each form safely, inspect metadata, and check that no content hides behind the navigation or overflows its container.

MagicBetting.BE was built solo this way: from an empty repository, section by section, from design to CI/CD. The lesson is the method, not the site: keep decisions in files, keep each change reviewable, and verify the connected website before launch.

Record what passed, what is left for the second pass, and which external settings still need a person. That note is the next agent's starting point.