How We Built A Manufacturer's Website From Scratch.

Full disclosure up front: the website you're reading was designed, coded and is maintained by WebsitePrism, a web design and development studio (registered in the UK as Website Prism Ltd, company no. 17462217) that shares a director with True Fit Sportswear. So this isn't an outside review — it's a candid write-up of how and why we made the decisions we did, including the things that went wrong.

The Starting Point

True Fit Sportswear began life online as a WordPress/WooCommerce store — a retail setup with shop, cart and checkout pages. But the business isn't a shop. It's a custom sportswear manufacturer in Sialkot, Pakistan, where every order is quoted, sampled and produced to a customer's own spec. A cart was the wrong tool, and the old site's pages, plugins and URLs were working against the one thing a B2B buyer needs most: confidence that a real factory is on the other end.

So the brief was simple to state and hard to execute: replace the store with a site that proves the factory is real, answers a buyer's questions before they ask, and gets found by people searching for exactly what the factory makes.

Why Hand-Coded PHP Instead Of A Page Builder

We chose a lightweight, hand-coded PHP site over another page-builder install, for three practical reasons:

• Speed by default. No plugin stack, no render-blocking bloat. Every page ships only the CSS and JavaScript it needs.
• One template, many pages. The 25 product category pages share a single template, as do the 25 city pages — so a fix or improvement made once reaches dozens of pages at the same time.
• Full control of the markup. Structured data, headings, canonical tags and image attributes are exactly what we specify, not what a plugin decides.

That's the approach behind our custom website development work generally: pick the simplest stack that does the job well, then build it properly.

Making It Fast

A buyer in the USA or UK opening this site is often on a mobile connection, so performance was treated as a feature, not a polish step:

• The above-the-fold CSS is extracted automatically from the main stylesheet and inlined, with the full stylesheet loading asynchronously — one source of truth, so the two can't drift apart.
• Images are served as properly sized WebP with real width and height attributes, so nothing jumps around as the page loads.
• The factory tour has dozens of videos, but none of them load until a visitor taps play — each tile is a lightweight poster frame until then.

Search, Structure And Real Content

Getting found meant more than titles and meta descriptions. The site now carries 25 product category pages, 25 city pages, 12 country-and-category pages for the USA, UK and Canada, and 15 buyer guides. The rule we held to: no templated copy swaps. City and country pages were each researched and written around genuinely different local facts — local sport culture, ports and logistics, regulations — rather than one paragraph with a place name changed.

Behind the content sits structured data: Organization and LocalBusiness, BreadcrumbList, Service, FAQPage, VideoObject and BlogPosting markup, generated from the page data so it can't fall out of step with what's on screen. The old store's URLs were mapped with permanent redirects (or cleanly retired) so existing search equity wasn't thrown away.

Ready For AI Search, Not Just Google

More buyers now ask an AI assistant "who manufactures custom cricket kits in Pakistan?" before they ever open a search engine. We built for that too: an llms.txt file summarising the business and its key pages, explicit allow rules for the major AI crawlers in robots.txt, and FAQ content written as direct, quotable answers with matching FAQPage schema.

The Trust Layer

For an overseas buyer deciding whether to wire money to a manufacturer they've never met, trust is the product. So we built it into the site: a public Business Verification page showing the real tax registration with a one-click link to check it on the government's own portal, a factory page with real footage, a portfolio of finished orders, and clear terms, refund and privacy policies.

Payments got the same treatment: a private payment-options page with bank-transfer, Wise and card options, and a Stripe checkout where the customer enters their own invoice reference. A signed webhook then emails both the business and the customer the moment a payment lands — so nobody has to chase a receipt.

What Went Wrong (And Got Fixed)

A case study that only lists wins isn't worth reading. A few real problems we hit and solved:

• Analytics were quietly broken. An audit found the wrong Google Analytics ID installed, so data had stopped flowing for days. Fixed as soon as it was found.
• A mobile layout bug. One long button label inside a two-column grid pushed a page wider than a phone screen. The fix — a single CSS rule — corrected it sitewide.
• A shared payment account. When one Stripe account served several websites, every site's webhook received every order. We now tag each checkout with its own site identifier and each webhook ignores anything that isn't its own.
• Hosting-level surprises. The host's CDN was overriding our security-policy header and throttling a couple of AI crawlers despite robots.txt allowing them — the kind of thing you only find by testing the live site, not the code.

What We'd Tell Any Business Planning A Website

1. Build for what your buyer is worried about, not for how the homepage looks.
2. Use real photos, real documents and real contact details wherever you can.
3. Treat speed, structured data and security as part of the build, not an add-on.
4. Test the live site — on a phone, with the crawlers, with a real payment — not just the local copy.