How to Build a Website with Codex

To build a website with Codex, open the correct project, describe the pages and behavior you need, let Codex implement them, and verify the running site before deploying it. Codex works with project files and tools, so your brief should identify the actual environment and what it is allowed to change.

For a business site, WordPress can supply content editing while Codex helps build the design. Niwa then handles relevant work after launch, such as customer questions and authorized website updates. Keeping these jobs distinct gives you a website you can maintain after the development conversation ends.

The example below is a fictional home-repair company that needs service pages and a working enquiry path. It follows the local-project route, rather than asking an agent to alter production first.

Open the project that will become the website

Choose an existing repository or a dedicated folder for the new site. Confirm that it contains the files you expect. If another person is working there, identify their changes before asking Codex to edit anything.

You can work through a supported Codex interface, including the CLI. In the terminal route, install and authenticate using the current official instructions, open your project directory and start Codex there. Official Codex CLI documentation.

For an existing WordPress site, make a local or staging copy with its active theme and relevant content. A folder containing an older theme is not sufficient evidence that you are editing the current website.

For a new build, decide whether you need a static page, a WordPress theme or an application with a separate backend. Tell Codex that choice. A framework is useful when it meets a requirement, but an ordinary service website does not need a newly invented CMS.

Give Codex the business job and the boundaries

Supply approved service descriptions, photographs, the coverage area and the contact destination. State how staff will update the pages. Then use a brief like this:

Build a WordPress website for [home-repair company] using the theme in this project. Visitors need to understand our services, view approved project photographs and send an enquiry. Staff need to edit service text and photographs through WordPress.

Inspect the relevant theme files and explain your implementation approach. Use native WordPress content and existing dependencies where they fit. Do not invent reviews, prices or qualifications. Do not change WordPress core, unrelated plugins or existing customer data.

Complete the homepage, services and contact journey on the local or staging installation. Verify mobile layout, keyboard navigation and a test enquiry. Show the changed files, test results and remaining setup before deployment.

Specify the permitted deployment target separately. Access to an SSH account is not an instruction to modify every domain hosted there.

Put durable project instructions in AGENTS.md

Codex reads project instructions from AGENTS.md. Use that file for a few stable rules that future tasks should follow. OpenAI’s AGENTS.md guide.

For this website, useful instructions might cover the active theme path, how to start the preview, which check command runs, and the requirement to preserve editable content. Keep private credentials out of the file.

An example instruction set could say:

Use the active theme in this repository. Preserve unrelated working changes. Reuse native WordPress functions and the existing contact plugin. Test the public page and editor after a change. Production deployment requires the named domain and an approved revision.

Avoid filling the file with speculative restrictions for features you do not have. Clear project facts are more useful than a long set of general slogans.

Build one complete customer journey first

Ask Codex to finish the service page through to the enquiry destination. The contact button should reach the right form or email action. A form needs an actual handler and a verified inbox or saved record.

Review the first running version before expanding the site. Check whether the repair company is understandable to a visitor who has never heard of it. Can that visitor find the service area, understand the next step and send a request?

Then extend the same content and design conventions to the remaining pages. A working service template can support several pages without hardcoding each page into a separate component.

Use an observable correction when something fails:

A visitor can submit the contact form, but the business inbox receives nothing. Trace the form destination and delivery evidence on staging. Fix the cause, send one controlled test and confirm where it arrived. Preserve the approved form fields.

This asks the agent to resolve a business failure, not just make the success message look convincing.

Review the changes and the running result

Inspect the diff. Ask Codex to explain new dependencies, removed files and changes to permissions or configuration. Ensure an unrelated feature has not been rewritten merely because the agent found it nearby.

Run the checks appropriate to the project. For WordPress theme work, that can include PHP syntax checks, page rendering and the block editor. For an application, use its established build and test commands. A successful build does not prove that a form delivers enquiries or that the correct version is live.

Check at least one narrow phone layout and a desktop layout. Test keyboard focus, menu operation, image loading and the complete enquiry flow. Try editing a service description through WordPress to verify the promised handoff.

If a test fails, preserve the result and ask for a focused repair. Do not ask the agent to deploy first and investigate later.

Add Niwa after the content and permissions are ready

The completed WordPress site can use the standalone Niwa AI plugin. Configure its supported model connection, approved services and customer rules, then test it as a logged-out visitor. Follow the Niwa installation guide.

For the repair company, Niwa can explain which service fits a customer’s request using the information the owner has supplied. When the work needs a site visit, it can check the configured availability, offer suitable times and book the visit directly during the WhatsApp conversation.

For the owner, Niwa can help make an approved service-page change in WordPress. Review the resulting public page. The website maintenance agent is relevant to that ongoing editing job; it does not replace the review of custom development code.

You can use your own supported AI subscription with no additional Niwa AI usage charges or Niwa-imposed usage caps on that connection. Provider limits still apply. Keep that runtime connection separate from whatever account you use for development in Codex.

Deploy an identified revision and verify it

Save the tested revision and a usable recovery point. Deploy only the files and content included in the approved change to the confirmed destination. Preserve live data and unrelated work.

After deployment, open the public domain in a private browser window. Verify the actual layout, contact delivery, HTTPS and key page metadata. Confirm that staff can still update the content. Keep the revision or package identifier with the deployment record so another person can tell what is running.

If the site is cached, use the host’s supported cache controls and check the served result again. A completed upload alone does not establish which page visitors receive.

When to hand the build to someone else

Codex can reduce development work, but someone still needs to assess the files, integrations and release. If you cannot verify those parts, provide the project to a developer with the brief, running instructions and test results.

Niwa Business is another route for this implementation. It includes a custom WordPress website or migration, hosting, maintenance and AI tools adapted to the business for USD 150. Existing WordPress owners can use the standalone plugin without ordering a replacement site.

Discuss the Codex project with Niwa. Include the repository or export, the current hosting destination and the customer action you need to work. A concrete handoff makes it possible to finish the website rather than leave a collection of generated files.