How I Built a Modern Raw PHP Business Website with OpenAI Codex: The Regal Pulp & Paper International BD Case Study

Disclosure: This article documents a real website project and a practical AI-assisted development workflow. The approximate attempt count is a count of major build and refinement passes, not an exact count of every prompt, file save or small correction.

When a business has a serious supply chain story, its website should feel dependable before a visitor reads every paragraph. That was the central challenge behind the new Regal Pulp & Paper International BD website. Regal is a Bangladesh-based international trade company serving paper, paperboard and allied-product customers as an exclusive agent and distributor. The business has international trade experience dating back to 1998 and was established as Regal Pulp & Paper in 2012.

The finished project is a ready-to-upload raw PHP website with a modern, responsive and slightly futuristic visual direction. It includes the public company website, an interactive contact page with Google Maps, structured product and service content, a gallery for events and occasions, documentation, a drag-and-drop page builder, a protected admin area, local JSON storage, security controls and technical SEO foundations.

This is the complete case study and tutorial: what the brief contained, how I worked with OpenAI Codex, the prompts that shaped the result, what was built, what I learned while uploading it to cPanel, and how another developer can repeat the process.

Project at a glance

Area	What was delivered
Business	Regal Pulp & Paper International BD, a Bangladesh-based paper and paperboard trade company
Technology	Raw PHP, HTML, CSS, vanilla JavaScript, JSON files and Apache configuration
Public pages	Home, About, Products, Services, Principals, Gallery, Docs, Contact, Custom Page and Privacy Policy
Admin tools	Login, settings, contact messages, gallery uploads and a drag-and-drop page builder
Gallery content	51 Papertech Expo images: 30 images from 2025 and 21 images from 2026
Contact	Two email addresses, three phone numbers, Dhaka and Chattogram office information and a Google Maps embed
Security	CSRF protection, secure sessions, a spam honeypot, rate limiting, upload restrictions, security headers and protected folders
SEO	Per-page titles and descriptions, canonical URLs, Open Graph, Twitter metadata, JSON-LD, robots.txt, sitemap.xml and llms.txt
Estimated major passes	About seven major build and refinement passes, with many smaller edits inside each pass

For the creative and design side of the work, you can also explore Tanur Graphics, the broader design practice behind this project. The site covers branding, packaging, print, web design and SEO, so the Regal project sits naturally at the intersection of visual communication and practical software delivery.

1. Start with the business brief, not the code

The first input was not a component library or a color palette. It was a company profile document. The source material explained that Regal Pulp & Paper International BD started with paper and allied products, works as an exclusive agent and distributor, and wants to bring paper, allied products and consumables under one roof as a one-stop solution for customers.

That information shaped the information architecture. A company like this does not need a noisy consumer-style storefront as its first screen. It needs to answer a few practical questions quickly:

• Who is Regal and where does it operate?
• What paper, paperboard and allied categories can it support?
• Can it represent an overseas principal responsibly in Bangladesh?
• How can a buyer request a quote or explain a grade, quantity and timeline?
• Can the team update event stories and future content without rebuilding every page?

The business brief also contained offices in Dhaka and Chattogram, phone numbers, two email addresses and the locations needed for a map. Those details became structured configuration instead of being scattered throughout templates. That one decision makes future updates much easier: a phone number or office address can be changed in one place.

2. Why choose raw PHP for this project?

For this website, raw PHP was a practical choice. The goal was a portable project that could be uploaded to ordinary shared hosting through cPanel File Manager. The site did not require a complex ecommerce database, a large plugin ecosystem or a build pipeline. A folder containing PHP files, CSS, JavaScript, images and writable storage is simple to move and easy to understand.

Raw PHP does not mean careless PHP. It means the project owns more of its decisions. The developer must deliberately handle input validation, output escaping, sessions, file permissions, uploads, email behavior, redirects, SEO and deployment. The official PHP manual is the right reference for the language and its built-in capabilities.

The main advantages for this project were:

• Portability: the site can run on a PHP-enabled host without Node.js or a database server.
• Low operational overhead: the final upload is a conventional document-root folder.
• Clear ownership: content, routing and templates are visible in the project files.
• Fast loading potential: there is no large framework runtime on the server.
• Future flexibility: a database, CMS or API can be introduced later if the business needs one.

The tradeoff is equally important: a raw PHP site requires disciplined maintenance. A future developer should keep PHP updated, change the default admin password, back up the storage folders and review every new upload or form handler.

3. How I used OpenAI Codex

Codex was used as a development partner inside an existing project folder. The most productive pattern was iterative: provide context, ask for a concrete implementation, inspect the result, test a narrow behavior, then give the next correction. The quality of the output improved when each prompt described the business, the existing files, the intended user and the acceptance criteria.

The workflow was not one magic prompt that produced a finished website. It was a sequence of focused passes:

1. Understand the company profile and the existing website situation.
2. Design the information architecture and visual language.
3. Create the raw PHP page and include structure.
4. Add content systems, contact handling and admin tools.
5. Add gallery events, stories and uploaded images.
6. Improve security, SEO, accessibility and responsive behavior.
7. Upload to cPanel, diagnose real hosting behavior and document the handoff.

Codex was particularly useful for keeping a long list of related requirements connected. It could work across a page template, a shared helper, a stylesheet and a JavaScript behavior while preserving the raw PHP approach. Human judgment was still essential: the business wording, the final content, the visual taste, the uploaded images, the hosting decisions and the decision to keep or reject a generated implementation all required review.

4. Step-by-step build process

Step 1: Inspect the source material and live context

Before writing templates, I extracted the meaningful business facts from the company profile. I checked the original site, reviewed the supplied Papertech Expo folders and mapped the requested features. This produced a compact project brief containing the company story, products, services, contacts, offices, event names and technical constraints.

For a new project, I recommend creating a simple discovery note with these fields:

Business name:
Primary audience:
Main customer action:
Products or services:
Locations:
Phone numbers:
Email addresses:
Existing images:
Required pages:
Admin or editing needs:
Hosting constraints:
SEO target phrases:

Step 2: Create a maintainable PHP structure

The project uses individual page files for direct hosting compatibility, shared includes for repeated layout, a data file for business configuration and storage folders for editable records. The key structure looks like this:

regalintbd.com/
|-- index.php
|-- about.php
|-- products.php
|-- services.php
|-- principals.php
|-- gallery.php
|-- documentation.php
|-- contact.php
|-- process-contact.php
|-- custom-page.php
|-- privacy-policy.php
|-- data/
|   `-- site.php
|-- includes/
|   |-- bootstrap.php
|   |-- functions.php
|   |-- header.php
|   |-- footer.php
|   `-- security.php
|-- partials/
|   `-- page-hero.php
|-- admin/
|   |-- login.php
|   |-- index.php
|   |-- messages.php
|   |-- gallery.php
|   |-- builder.php
|   |-- settings.php
|   `-- process-*.php
|-- assets/
|   |-- css/styles.css
|   |-- js/main.js
|   |-- js/builder.js
|   |-- img/
|   `-- uploads/gallery/
|-- storage/
|   |-- messages/
|   |-- builder/
|   `-- gallery/
|-- .htaccess
|-- robots.txt
|-- sitemap.xml
`-- llms.txt

Every public page loads the same bootstrap file. The bootstrap loads security and helper functions, then the page can use the central site configuration. This keeps the pages readable and prevents duplicated logic from growing in multiple places.

Step 3: Centralize content and SEO inputs

The `data/site.php` file contains the site name, tagline, description, keywords, year information, contact details, offices, navigation, product categories, services, values and page metadata. This is a small but powerful content model. It means the first version can stay database-free while still being dynamic enough for a business website.

Central configuration also made the contact page and footer consistent. Both email addresses are rendered from the same source: `[email protected]` and `[email protected]`. The same principle applies to phone numbers and office addresses.

Step 4: Build the responsive frontend

The visual direction combines a dark technical canvas, bright red brand accents, cool blue interface highlights and generous white content surfaces. The hero image gives the business a first-viewport signal: rolls, paperboard, shipping and trade coordination. The rest of the interface stays focused on scanning and action rather than decoration.

The responsive layer was designed around real use, not just a desktop screenshot. Navigation collapses into a mobile menu, grids reduce their columns, forms stack, hero typography remains controlled, buttons stay usable and the gallery adapts to narrow screens. The MDN responsive design guide is a useful reference for the layout principles behind this kind of work.

The important design decision was to give every page a job:

• Home: communicate reliability and move visitors toward products or an inquiry.
• About: explain history, purpose and values.
• Products: make supply categories easy to scan.
• Services: explain sourcing, agency, distribution and coordination.
• Principals: speak directly to overseas suppliers seeking Bangladesh representation.
• Gallery: turn events and occasions into understandable stories.
• Docs: make maintenance and handoff less dependent on the original developer.
• Contact: make a real inquiry possible with grade, quantity, timeline and message fields.

Step 5: Make the contact page dynamic

The contact page was treated as a business workflow rather than a decorative form. A visitor can select an inquiry topic, include a quantity or timeline, write a requirement and choose between email, phone, WhatsApp or the map. The page includes the Dhaka office map embed and a direct Google Maps link.

When the form is submitted, the PHP handler validates the request, checks a CSRF token, rejects the hidden honeypot field when it is filled, applies a short rate limit, validates the email address and stores the message as a JSON line. It also attempts to send the inquiry to the configured business email through the hosting server’s `mail()` function. If mail delivery is not configured by the host, the saved message remains available to the admin inbox.

This is a useful pattern for a small business site: the mail channel can fail without silently losing the lead. For a higher-volume business, the next step would be SMTP or a transactional email service, plus a database and a proper queue.

Step 6: Add a protected admin area

The admin area provides a small operational dashboard instead of forcing every update through code. It includes:

• A login screen with a default password that should be changed immediately.
• A dashboard showing inquiry volume and the most recent submission.
• A message view with contact details and CSV export.
• A settings screen for changing the admin password.
• A gallery manager for uploads and story metadata.
• A drag-and-drop builder for a reusable dynamic page.

The admin login is intentionally small and understandable. It uses PHP sessions, session regeneration after login, a session timeout and a password hash in `admin/config.php`. The default credentials in the handoff documentation are `admin` and `ChangeMe#2026`; those credentials are a starting point only and must be changed immediately after deployment.

Step 7: Build a lightweight drag-and-drop page builder

The builder was designed for a nontechnical website owner who may want to assemble a campaign or capability page later. It currently supports reusable block types such as Hero, Feature, Metrics and CTA. Blocks can be dragged into a canvas, edited, reordered and saved as JSON. The public `custom-page.php` template reads that JSON and renders the selected blocks safely.

This is not intended to replace a full page-builder ecosystem. It is a focused tool for a specific business site. That narrow scope keeps the data model understandable and reduces the attack surface. Adding a new block means updating the JavaScript editor, the server-side sanitizer and the PHP renderer together.

Step 8: Turn the gallery into stories

The gallery is one of the most distinctive pieces of the project. The request was not simply to place images in a grid. Visitors should understand what an event was, why it mattered and what they should notice. Each gallery item therefore includes a title, category, event, occasion, date, alt text, summary and longer story.

The two supplied events appear in one gallery with separate event filters:

• Papertech Expo 2025: 30 imported images documenting trade-floor presence, booth engagement and industry conversations.
• Papertech Expo 2026: 21 imported images, including an exhibitor recognition moment and continued event participation.

Images were given clean filenames and stored in `assets/uploads/gallery/`. Metadata was stored in `storage/gallery/gallery.json`, which allows the public page to remain dynamic without a database. The frontend combines category filters and event filters, opens a story modal, supports keyboard-friendly controls and keeps both business contact emails visible for expo follow-up.

The admin upload form accepts JPG, PNG, WebP and GIF files under 5 MB. It asks for an accessible image description and story text because a useful gallery should give context, not just visual noise.

Step 9: Add security while the site is still small

Security was treated as part of the first implementation, not a last-minute plugin. The project includes:

• CSRF tokens on contact, login, settings, builder and gallery forms.
• Output escaping through a shared helper before values are printed into HTML.
• A honeypot field and simple rate limiting for contact spam.
• Session cookies marked HttpOnly and SameSite, with HTTPS-aware secure cookies.
• Content Security Policy and other response headers in `.htaccess` and the PHP security bootstrap.
• Extension, MIME and size checks for gallery uploads, plus controlled filenames.
• Protected `data`, `includes`, `partials`, `storage` and admin configuration directories.
• Directory listing disabled with `Options -Indexes`.

These controls follow familiar web security principles. The OWASP CSRF reference explains why state-changing forms need request tokens. Security is never finished, but building the first version with these boundaries is much safer than bolting them on after an incident.

Step 10: Make the site understandable to search engines and AI agents

Each page has a title, description and keyword set. The shared header adds a canonical URL, robots directive, Open Graph fields, Twitter card fields, theme color and the hero image. The site also outputs Organization JSON-LD so a crawler can identify the business entity and contact information.

The project includes three small but important discovery files:

• robots.txt points crawlers toward the sitemap and avoids private areas.
• sitemap.xml lists the public pages.
• llms.txt gives AI systems a concise business summary, page map and contact details.

Metadata does not replace useful content. A keyword field is not a shortcut to rankings. The most important SEO work remains clear page purpose, specific language, fast loading, accessible images, good internal linking and a website that answers a real visitor’s question. Google’s SEO Starter Guide is a useful external reference, and Schema.org Organization documents the structured data vocabulary used by the site.

5. What the final Regal website includes

Home and company positioning

The home page opens with the line “Reliable paper and paperboard trade support in Bangladesh.” It immediately identifies Regal as an international trade company and presents two next actions: send an inquiry or view products. The following sections explain the company’s focus, values, supply categories and quote process.

This is a deliberate B2B structure. A buyer does not need a long marketing speech before seeing how to start a conversation. An overseas principal also needs a clear indication that Regal understands representation, distribution and local follow-up.

Products, services and principals

The product page groups the offer into Paper & Paperboard, Packaging & Allied Materials and Agency Products. The service page describes International Sourcing, Exclusive Agency & Distribution, Customer Requirement Matching and Import & Coordination Support. The principals page frames the company as a potential Bangladesh market partner for overseas suppliers.

These are intentionally separate pages. When each audience question has its own URL, the content is easier to share, index and expand later. Direct pages also give the admin a natural place to add more detail without turning the home page into a wall of text.

Documentation

The documentation page is part of the product, not an afterthought. It explains project structure, content updates, the builder, gallery management, SEO, security, launch requirements and permissions. This makes the handoff more durable, especially when the person maintaining the site is not the person who wrote the first version.

Responsive interaction

The site is built to work across desktop, tablet and mobile widths. Interactive elements include the mobile navigation, product filters, gallery category and event filters, gallery modal, upload preview, delete confirmation and builder drag-and-drop interactions. The CSS uses stable layout constraints so content changes do not unexpectedly resize buttons, tiles or controls.

6. Prompt library: prompts that can create a similar site

The following prompts are starting points, not universal recipes. Replace the bracketed details with the real business context. The best results come from asking Codex to inspect existing files first and to keep changes inside the requested scope.

Prompt 1: discovery and architecture

Act as a senior PHP product engineer and information architect. Inspect the files in this project before editing anything. I need a ready-to-upload raw PHP website for [business name], a [business type] serving [audience] in [location]. Use the supplied company profile as the source of truth. Propose a page map, shared include structure, centralized content configuration, storage approach and launch checklist. Keep the stack portable for cPanel hosting and avoid introducing a framework or database unless there is a clear need.

Prompt 2: visual direction

Design and implement a modern responsive B2B website for [business name]. The audience is [audience]. The visual language should feel [three adjectives], with a clear first-viewport signal for [product/service]. Use real supplied images where available. Create a full usable website, not a marketing mockup. Use a restrained color system, readable typography, compact content sections and clear actions for [primary action] and [secondary action]. Keep all layout stable on mobile and desktop.

Prompt 3: raw PHP foundation

Build the public pages as individual PHP files so they work on ordinary Apache shared hosting. Add includes/bootstrap.php, includes/security.php, includes/functions.php, includes/header.php and includes/footer.php. Centralize site content in data/site.php. Escape output, keep templates readable, add a shared page metadata helper and do not duplicate contact information across templates. Use absolute site paths only where the current hosting setup supports them.

Prompt 4: contact flow

Add a dynamic contact page for [business name]. Include name, company, email, phone, inquiry topic, quantity or timeline and message. Add a Google Maps embed for [office address] and direct email, phone and WhatsApp links. Implement CSRF protection, a honeypot, rate limiting, validation, JSONL storage and a mail() attempt. Never lose a valid lead if mail delivery is unavailable; show stored submissions in a protected admin screen.

Prompt 5: secure admin

Create a small protected admin area for this raw PHP site. Include login, logout, session timeout, password hashing, settings, contact message review and CSV export. Use CSRF tokens for every state-changing form. Protect data and storage directories. Do not expose passwords in the frontend. Add a clear first-login reminder to replace the default credentials.

Prompt 6: gallery with stories

Add a dynamic gallery system without a database. Admin users must be able to upload JPG, PNG, WebP and GIF images under [size] MB, enter title, category, event, occasion, date, alt text, summary and story, then delete an item. Store metadata as JSON and files under a controlled upload directory. The public gallery must support event filters, category filters, an accessible modal, responsive cards and story copy that explains why each image matters.

Prompt 7: drag-and-drop builder

Add a focused drag-and-drop page builder to the PHP admin area. Start with Hero, Feature, Metrics and CTA blocks. The editor should allow adding, reordering, editing and removing blocks. Save a sanitized JSON document and render it through a server-side PHP template. Include a published toggle, page title and description. Keep the block schema small and document how a future developer can add another block safely.

Prompt 8: technical SEO

Audit the entire PHP site for technical SEO and agent readability. Add unique page titles and descriptions, canonical URLs, robots directives, Open Graph, Twitter metadata, Organization JSON-LD, robots.txt, sitemap.xml and llms.txt. Keep metadata truthful and based on the business content. Add useful alt text and internal links. Check that private admin and storage paths are not listed as public pages.

Prompt 9: responsive QA

Review the site at mobile width 390px, tablet width 768px and desktop width 1440px. Look for horizontal overflow, overlapping text, buttons that resize unexpectedly, unreadable controls, broken image crops, inaccessible dialogs and navigation failures. Make focused fixes in the existing CSS and JavaScript. Preserve the design direction and do not rewrite unrelated modules.

Prompt 10: cPanel deployment diagnosis

Diagnose this raw PHP website after cPanel upload. The home page loads but CSS or clean URLs may fail. Give me a checklist using only File Manager and the browser: document root, folder permissions, file permissions, .htaccess, PHP version, writable storage directories, direct .php URLs, asset URLs and cache behavior. Explain the fastest fallback if mod_rewrite is not active.

7. How to run the PHP site locally

A raw PHP website needs a PHP server. Opening `index.php` directly from Finder is not the same as running PHP; the browser will not execute the server-side code. PHP’s built-in development server is enough for a basic local check. The PHP built-in web server documentation explains the same workflow.

From Terminal, enter the project folder and run:

cd "/Volumes/MS-Design/Others/tanu/Regal Int"
php -S localhost:8000

Then open http://localhost:8000/. To stop the server, return to Terminal and press Control-C.

On macOS, PHP may not be installed by default. Homebrew is one option, but the command only works after Homebrew itself is installed and available in the shell. MAMP is often easier for a nontechnical local preview because it bundles Apache and PHP with a visual control panel. On Windows, XAMPP or Laragon are common choices; put the project inside the web root and start Apache/PHP. The exact local URL depends on the app.

Static Python preview is useful only for checking assets:

python3 -m http.server 8000

It will not execute PHP, process the contact form, authenticate the admin area or run the upload manager. Use PHP, MAMP, XAMPP or Laragon for a real test.

8. How to upload to live cPanel hosting

Upload the contents of the project folder into the domain’s document root. In cPanel this may be `/home/account/regalintbd.com`, `public_html` or another domain-specific directory. The correct location is the folder that already serves the domain’s homepage.

1. Make a backup of the current live folder before replacing files.
2. Upload the PHP files, folders, assets, `.htaccess`, `robots.txt`, `sitemap.xml` and `llms.txt`.
3. Keep the folder hierarchy intact. Do not put `styles.css` beside `index.php` if it belongs in `assets/css/`.
4. Use PHP 8.0 or newer in cPanel MultiPHP Manager when available.
5. Make `storage/messages/`, `storage/builder/`, `storage/gallery/` and `assets/uploads/gallery/` writable by PHP.
6. Keep public files readable: a common starting point is 644 for files and 755 for folders.
7. Open the homepage, a direct CSS URL, a direct JavaScript URL, the contact page and the admin login page.
8. Change the admin password before sharing the site publicly.

A common cPanel mistake is uploading folders with permissions such as 0700. The server may execute the homepage but be unable to read CSS, JavaScript or images. If the site appears as plain unstyled HTML, check a URL such as `https://regalintbd.com/assets/css/styles.css` directly in the browser. If it returns 404 or permission denied, fix the path or permissions before debugging the PHP layout.

A second common issue is Apache rewrite support. The project includes `.htaccess` rules that allow clean paths such as `/about` to resolve to `about.php`, but the host must allow overrides and support `mod_rewrite`. If `/about` returns 404 while `/about.php` works, either repair the `.htaccess` setup or use direct `.php` navigation links. The Apache mod_rewrite documentation explains the server-side behavior. On shared hosting, the host may need to enable the feature.

cPanel’s File Manager documentation is useful when checking paths, permissions and the editor. Always test the live domain after uploading, because local Apache behavior and the hosting server’s configuration may differ.

9. How many attempts did this project take?

The honest answer is approximately seven major passes. This is not a precise counter of every Codex exchange, because many small improvements happened inside one pass and some work involved examining files or uploading assets rather than generating new code.

1. Discovery and initial scaffold: review the company profile, define the page map and create the raw PHP project.
2. Frontend design pass: create the brand direction, responsive layout, hero treatment, shared header/footer and public pages.
3. Business workflow pass: add products, services, principals, contact details, Google Maps and inquiry handling.
4. Admin and documentation pass: add authentication, message review, settings, documentation and the builder foundation.
5. Gallery pass: add upload handling, story metadata, filters, modal interaction and responsive gallery behavior.
6. Papertech content pass: import the 2025 and 2026 event images, add event stories and preserve both contact emails.
7. Launch and deployment pass: tighten responsive behavior, check SEO and security, prepare hosting instructions and diagnose cPanel permissions and route behavior.

Within those seven passes there were many smaller edits: changing copy, refining spacing, checking images, correcting paths, improving form behavior and testing live URLs. That is normal. Website development is closer to a loop of brief, build, observe and refine than a single act of generation.

10. What I learned from the project

AI is strongest when the acceptance criteria are concrete

“Make it modern” is a starting direction, not a test. “Make the gallery filter by event and category, open an accessible story modal, support future uploads and keep both email addresses visible” is an acceptance criterion. Codex can make better decisions when the prompt states what a visitor must be able to do.

Content architecture matters as much as visual polish

The central site configuration and JSON storage made the website easier to maintain than a collection of hard-coded paragraphs. Even a small raw PHP site benefits from a simple content model.

Deployment is part of the product

A website that looks perfect locally but fails in cPanel is not finished. File permissions, PHP versions, writable directories, rewrite rules, mail configuration and cache behavior need to be included in the handoff. In this project, real hosting behavior exposed two practical checks that are easy to miss: uploaded asset folders must be readable, and clean URLs depend on Apache configuration.

Stories make galleries more useful

An event gallery is stronger when every image has an explanation. A title, event name, short summary and story help a visitor understand the company’s participation and give a future sales conversation a useful context.

Security belongs in the first version

Forms and uploads are normal parts of a business website, so CSRF protection, validation, output escaping and permissions should be designed before the first public upload. Small sites are still exposed sites.

11. What could be added next?

The current site is intentionally database-free and portable. Future versions could add a MySQL content layer, SMTP delivery, admin roles, image resizing, automatic WebP conversion, versioned builder pages, search, multilingual content, product detail records, supplier profiles and analytics dashboards.

Those additions should be driven by a real operational need. A database is valuable when content volume or reporting justifies it; it is not automatically better than JSON for a small brochure and inquiry site. The next technical step should be chosen based on how Regal’s team actually maintains the business, not on the size of a framework’s feature list.

12. A reusable launch checklist

• Confirm the domain points to the intended document root.
• Open the homepage and every public page on desktop and mobile.
• Open the CSS and JavaScript files directly to verify asset paths.
• Check image loading and gallery modal behavior.
• Submit a real test contact message and confirm it appears in admin messages.
• Confirm the mail address and hosting mail configuration.
• Change the default admin password.
• Confirm storage and upload folders have the right permissions.
• Check `robots.txt`, `sitemap.xml` and page source metadata.
• Test clean URLs. If rewrite rules are unavailable, use direct `.php` URLs consistently.
• Back up the site files and JSON storage after the first live content update.

Conclusion

The Regal Pulp & Paper International BD project shows how a focused raw PHP website can still feel modern, interactive and ready for future content. The result is not only a homepage. It is a small business platform with a coherent public story, a real contact path, an updateable gallery, a page builder, documentation and technical foundations for search and AI readability.

The bigger lesson is about process. Codex can accelerate the distance between an idea and a working implementation, but the best output comes from giving it strong context, checking the actual result, and continuing through the unglamorous parts: image paths, permissions, mobile spacing, rewrite rules, mail behavior and handoff documentation.

Visit the live Regal Pulp & Paper International BD website to see the final design, and explore Tanur Graphics for related branding, packaging, website and SEO work. For a deeper look at the broader design practice, the Tanur Graphics blog contains additional design and technology articles.

Focus keyword: build a PHP website with Codex