Case study · Testure Industries

Bringing a manufacturer trusted since 1978 to laboratories around the world.

Brand, website, CMS and search for Testure Industries, the export division of Sharma Scientific Co. Launched on 24 August 2026, it was bringing in enquiries from India and overseas within its first month, with no paid advertising.

Client work. Sole developer and consultant across brand strategy, design, frontend architecture, content, SEO and deployment — and the client's technical partner since launch.

The Testure Industries homepage: the headline “Precision instruments, refined for the bench.” above a studio photograph of a BOD incubator, thin film oven, RTFO and curing tank, with temperature and humidity specification cards.

The problem

Carrying an established reputation across borders.

Testure Industries is the export division of Sharma Scientific Co., which has manufactured laboratory and testing equipment in Delhi since 1978 — a track record built over decades of installations with Indian laboratories. International procurement teams evaluate suppliers remotely, through specifications, certifications and how a company presents itself online. The website's job was to carry that track record to them, clearly and in the terms they buy in.

01

Every detail is part of the evaluation

A laboratory specifying a stability chamber is making a considered institutional purchase, often from the other side of the world. Specifications, certifications, the export process and the finish of the site itself all inform that decision, so each had to be complete, precise and consistent.

02

The catalogue moves at the factory's pace

Products, models and specifications change on the manufacturer's schedule. The team needed to publish those changes themselves, the moment they happen, without routing every update through a developer.

03

Buyers search for equipment, not suppliers

Procurement starts with what a lab needs — a BOD incubator, a compression testing machine — rather than with a company name. Every product and category page was structured to be found exactly that way.

What I built

The scope of the engagement.

The Testure Industries export page, headlined “India-engineered. Pacific-ready.”, above a dotted world map with arced shipping routes radiating from Delhi to Australia and New Zealand.

The full site design

Homepage, product catalogue, category and product detail pages, export/global, about and contact, designed and built rather than assembled from a template.

A Testure Industries product page for a bacteriological incubator, model BI-01, showing the product photograph, its description and the quote request, WhatsApp and call sales entry points.

A multi-step inquiry flow

A staged quote request capturing contact, requirement, model configuration, quantity, timeline and destination country. Arriving from a product page, it opens already carrying that product and its model number, and WhatsApp conversations started from a product name it in the first message.

Brand strategy and positioning

Positioning Testure as a dedicated export brand with its own identity, grounded in the parent company's manufacturing heritage.

A catalogue the client controls

Seven Sanity document types authored from scratch, covering products, categories, certifications, export regions, testimonials, free-form pages, and a homepage configuration singleton.

A content pipeline, not just a CMS

CLI scripts that seed the homepage configuration and sync the product catalogue into Sanity, so the initial content load and later bulk corrections are repeatable instead of manual.

Email delivery without a backend

One hardened enquiry handler behind both public routes, delivering through Resend and returning a reference number that the buyer and the factory both see.

A complete search layer

Per-page metadata and canonicals, Open Graph and Twitter cards, structured data, a sitemap generated from live CMS content, robots rules, and search console verification.

Launched, and bringing in buyers

Live at testureindustries.com since 24 August 2026, on Vercel. In its first month, through organic search and with no paid campaigns, four to five buyers reached out through the site: two from overseas, the rest from India.

Ongoing ownership

Frontend architecture, performance and SEO remain mine after launch, not handed back at delivery.

How it works

Two loops that meet in the CMS.

The client's loop

  1. The factory updates a product, a specification or a page in Sanity Studio.

  2. The change is saved to the content dataset.

  3. The live site picks it up on its next revalidation, without a deployment.

The buyer's loop

  1. A buyer finds a product page through search.

  2. The page is served from cache, already rendered, with its specifications and structured data in place.

  3. They request a quote from that product, or through the staged inquiry form.

  4. The submission is validated and rate-limited at the API route, delivered by email to the factory, and answered with a reference the buyer can quote back.

The client never waits for me to publish. The buyer never waits for the page to build.

For engineers

The engineering behind it

Everything below is written for engineers. If you came to judge the work as a prospective client, you already have what you need — this is where the decisions, the trade-offs and the reasoning behind them live.

Hardest problems

Problem, why it’s hard, how it was resolved.

01

A CMS-driven site that must never render empty

Why it’s hard

Every section of the homepage is CMS-driven, which means every section can also be missing — an unseeded dataset, a deleted document, a client mid-edit. The usual outcomes are a blank band where a section should be, or a page that throws. Both undermine a site whose purpose is to present a manufacturer at its best.

Resolution

The homepage configuration, the inner page content and the export region data each have a typed static fallback compiled into the build, and the fallback resolves field by field rather than per document. A field the client has never filled takes its default, so one unfinished field cannot blank a whole section; a field the client deliberately empties stays empty, so hiding a section from the Studio still works.

02

Public form endpoints with no database and no accounts

Why it’s hard

Two endpoints that send email are exactly what bots find first, and there is no user table, no session and no persistence layer to defend them with. Leaving them open means an inbox full of spam and damage to the sending reputation of a newly launched domain.

Resolution

Both routes run through a single shared request guard before any work happens: POST only, JSON content type required, a 20,000 byte body cap enforced on the body actually read rather than on a header the client controls, an origin allowlist that treats the apex and www hosts as one, and a per-IP counter capped at 10 submissions per 15 minutes. An off-screen honeypot field catches form bots, which are answered exactly as a real buyer would be so they stop probing.

03

Email delivery that cannot fail silently

Why it’s hard

Resend's SDK reports a rejected send by resolving with an error object rather than throwing, so the obvious integration — await the call, show success — confirms enquiries that never left. On a site whose only conversion is the enquiry, that is the worst failure available, and nothing about it would be visible to either side: the buyer believes it arrived, the factory never sees it.

Resolution

Both public routes delegate to one handler that inspects the provider's response rather than trusting the call, logs any failure with enough context to trace it, and shows the buyer a phone number, WhatsApp and email address instead of a false confirmation. The reference number is issued by the server, so the one the buyer sees is also on the factory's copy of the email. Every guard path — method, content type, origin, body size, rate limit, honeypot — was exercised before relying on it.

04

Motion-heavy design against a mobile performance budget

Why it’s hard

The design leans on parallax, scroll reveals, an animated world map and four typefaces to carry the credibility argument — and the buyers it is arguing to are frequently on mobile. Every element doing the persuading is also a cost against the thing that determines whether the page is seen at all.

Resolution

Image delivery was tightened rather than the design cut back — AVIF and WebP output, a constrained quality ladder, long-lived cache headers, and a single preloaded image per page so nothing competes with the hero for early bandwidth. The animated world map draws from a 344 KB geometry library that never reaches the browser: the map is rendered once at build time into a 24 KB cached SVG, with only the route animation running client-side. The navigation fetches just the product names it displays rather than the catalogue behind them, and the homepage ships at around 320 KB of HTML.

05

Building search visibility for a new domain

Why it’s hard

A newly launched domain has no search history or inbound links yet, so every signal it sends has to be clean. A duplicate URL, a missing canonical or an outdated sitemap each dilute the limited attention a crawler gives a new site.

Resolution

Page metadata is generated through a single factory that merges CMS-authored SEO fields over per-page fallbacks and always emits a canonical, so no page can ship without one. The sitemap is generated from live GROQ queries and leaves out categories with no products, which are also served noindex until they have stock. Every listing page carries an h1 naming the equipment rather than a generic label, product and category pages carry BreadcrumbList, and listings carry ItemList. Product markup is deliberately left out: its rich results require a price or genuine reviews, and a quote-based catalogue has neither, so the markup could only ever generate errors.

06

Deciding what the site should not have

Why it’s hard

Sections that have been designed and built feel like assets, which is exactly what makes them hard to cut. An industries section of thirteen pages covered 17 of the 40 products, missed the construction range entirely — a third of the catalogue — and repeated the same few items from page to page. A standalone catalogue page duplicated the product listing and competed with it for the same search terms.

Resolution

Both were removed, with permanent redirects so any ranking or shared link carried over to the product listing. The decision was taken on evidence rather than preference — catalogue coverage, overlap with the product listing, and what Search Console showed each section earning. It was also the right call for the client, who runs the CMS without a developer and now has one fewer content type to keep in step with a catalogue it did not match.

07

Security headers on a marketing site, unprompted

Why it’s hard

Security headers are rarely requested for a marketing site, and their absence goes unnoticed until it matters. This site represents a manufacturer to institutional buyers, and institutional buyers run security scans.

Resolution

HSTS with preload, X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a strict-origin referrer policy, a Permissions-Policy denying camera, microphone, geolocation, payment and USB, and a Content Security Policy locking down base-uri, form-action, frame-ancestors and object-src. The X-Powered-By header is disabled. Structured data escapes angle brackets before it is written into the page, so a CMS value containing a closing script tag cannot break out of it.

Architecture

Two paths that meet at the content layer.

Publishing and serving are separate paths. They meet only at the content layer — the client's edit does not trigger a deployment, and the buyer's request does not wait for one.

Publish path · the client

Sanity Studio

hosted by Sanity, not embedded in the app

Sanity dataset

the content layer both paths share

The Studio is hosted by Sanity rather than embedded in the application, so the client’s editing tool cannot be broken by a site deployment.

read at request time

GROQ queries

products, categories, industries, pages

content returned

ISR cache

60s revalidation — no deployment needed

Resilience branch · query returns nothing

Typed static fallback content

compiled into the build — not a separate service

renders instead of a gap

Rendered page

CMS content when present, fallback when not

This is the only place the publish path and the request path meet. A client edit never triggers a deployment, and a buyer’s request never waits for one.

served from the edge cache, already rendered

Request path · the buyer

Buyer

arrives from a search result

Vercel edge / ISR cache

no render on the critical path

Product or category page

specifications and structured data in place

inquiry submitted

Next.js API route

/api/inquiry · /api/contact

Shared request guard

method · content-type · body cap · origin allowlist · per-IP rate limit

Resend

transactional delivery

Factory inbox — the actual deliverable. The outcome of this system is an email arriving at the factory, not a page rendering.

Build-time & ops · separate from request flow

CLI seed + sync scripts

repeatable content loads into the dataset

GA4 + Microsoft Clarity

route-level pageviews from the rendered page

Content & request flowFallback / build-time & ops

Decisions and what's next

Complexity spent where it pays, and a roadmap for the rest.

This is a live engagement, sized to a site with real buyers and a client who runs it without a developer. These are the calls I made about where complexity earns its keep, and where the work goes next.

Rate limiting sized to the traffic it serves

Submission limits are enforced in memory on each serverless instance: no extra service to run, pay for or keep healthy, and enough to turn away casual abuse at this site's volume. A shared, durable counter is a drop-in upgrade when traffic calls for it, not a rewrite.

Publishing within a minute, with nothing extra to break

Pages refresh from the CMS on a sixty-second cycle, so the client's edits are live within a minute with no webhooks, queues or deploy hooks in between. Instant publishing is a small, contained upgrade if the business ever needs it.

Every change checked against the site buyers see

The codebase is typed end to end, and every change goes through type checks, lint and a full production build before it ships. Refactors were verified against the built output itself — the rendered HTML of every product and category page compared before and after, to prove nothing a buyer sees had moved — and layout work was checked in a real browser at desktop and narrow widths.

Next: a receipt in the buyer's inbox

An enquiry already produces an on-screen reference and a detailed email to the factory. A confirmation to the buyer carrying the same reference is next, and it reuses the delivery path that is already in place.

Next: editing directly on the page

The client already updates the catalogue without me. The next step is click-to-edit on the live page through Sanity's Presentation tool — specified down to draft-aware fetching and a guarded preview route — so a non-technical owner sees exactly what he is changing as he changes it.

The engagement did not end at launch. It is still working down this list.

Stack

Next.js 16 (App Router)React 19TypeScriptTailwind CSS 4Aceternity UIFramer MotionSanity CMS with authored schemas and GROQResendVercelGoDaddy DNSGA4 + Microsoft ClarityGoogle Search Console

An established manufacturer, handled end to end: positioning, design, a content system the team runs themselves, and search built for international buyers. Within a month of launch, with no paid advertising, the site was bringing in enquiries from India and overseas. The partnership continues.