Case record · Manufacturing

Manufacturing company website design:
smmtools.co.in

A precision tooling manufacturer with nine product families and roughly 120 catalogue entries, maintained by two people. Seven weeks from discovery to live. It has been in production ever since, and you can open it now.

Open smmtools.co.in

Record SMM-01

The engineering record

Sector: Precision tooling and machinery manufacture
Live at: smmtools.co.in
Stack: Next.js 14 (App Router) · TypeScript · Tailwind CSS · PostgreSQL · Nginx on a single VPS
Timeline: 7 weeks, discovery to live
What it carries: 9 product families, ~120 catalogue entries; 30–60 quote requests a month; roughly 2,500 sessions a month, about half from search

figures rounded, and honest

The smmtools.co.in home page: product families, technical catalogue and quote request — Captured from the live deployment. Nine product families across the top, a technical catalogue underneath, and a quote request that follows the buyer down the page.

The brief— what this site has to do

A catalogue is not a brochure.

A manufacturer's website carries a job most agency portfolios never have to think about. The visitor is rarely browsing. They are a purchase engineer or a workshop owner who already knows roughly what they need, and they have arrived to answer two questions: does this company make the thing in my specification, and are they credible enough to send a drawing to. Everything else on the page is in the way of those two questions.

That shaped the whole build. Nine product families and around 120 catalogue entries is enough content to get lost in and not enough to justify a search platform. The maintenance reality mattered even more: two people update this catalogue, alongside their actual jobs, a handful of times a year. Any architecture that assumed a full-time content team would have decayed within two quarters — which is the real reason so many manufacturer websites still show a 2019 product range.

So the target was narrow. Make every product family findable in one step from anywhere on the site. Make the technical detail scannable rather than paragraphed, because a purchase engineer reads specifications the way the rest of us read a train timetable. Make the quote request short enough that someone will finish it on a phone in a workshop, and make it impossible for that enquiry to be lost afterwards. And keep the whole thing cheap to run, because a manufacturing SMB should not be paying platform rent on a site that changes four times a year.

Decisions— the choice, the reason, and the consequence

Three calls that shaped the build.

Decision 01

Catalogue pages are statically generated and rebuilt on publish, not rendered per request.

Why

Product data changes a few times a quarter, not a few times an hour. Static pages meant the site stays fast on a modest single-server setup and survives a traffic spike without us being on call for it.

What it means in practice

In practice this means the server does no work when a catalogue page is requested — it hands over a file that was rendered when the content was last published. A page that is already built cannot be slow because the database is busy, and it cannot go down because a query went wrong at the moment a buyer arrived.

The trade is real and worth stating: publishing a change requires a rebuild, so the catalogue is not editable in the ten seconds before a customer visit. For a catalogue that moves quarterly, that is a fair price for a site that never needs anyone on call. For an inventory page showing live stock, it would be the wrong call entirely — which is why the warehouse system is built the opposite way.

Decision 02

The quote request writes to Postgres first and sends email second.

Why

Email is the part most likely to fail quietly. Storing the enquiry before anything leaves the server means a mail outage costs a delayed notification, never a lost lead.

What it means in practice

Almost every enquiry form on the Indian SMB web is a single call to a mail service. When that call fails — an expired API key, a provider outage, a spam filter that starts silently discarding — the enquiry does not bounce. It evaporates. Nobody finds out, because the failure looks exactly like a quiet week.

Writing the row first inverts that. The notification email becomes a convenience rather than the system of record, and the worst case degrades from “we lost a quote request” to “we saw it a few hours late.” For a business where a single enquiry can be a substantial order, that is the difference the architecture exists to buy.

Decision 03

No CMS. Catalogue content lives in typed data checked into the repository.

Why

A two-person team updating a technical catalogue quarterly does not need a login and an editor. Types caught the spec mismatches a CMS would have let through.

What it means in practice

A CMS looks like the safe default until you count what it actually costs a small team: a login to remember, an editor to learn, an upgrade path to maintain, and a permanent risk that a mistyped specification goes live because free-text fields accept anything.

Typed catalogue data changes that. A missing specification or a family that no longer matches its products fails before it ships rather than after a customer notices. The cost is that the client cannot edit catalogue content without us, which we said plainly at the time — for a quarterly update cycle it was the right trade, and for a client wanting to publish weekly it would not have been.

The numbers— read carefully

What it does in a normal month.

Roughly 2,500 sessions a month, about half of them arriving from search, producing somewhere between 30 and 60 quote requests. Those are rounded figures and they are steady rather than spectacular.

It is worth being precise about what they do and do not mean. Thirty to sixty enquiries out of about 2,500 sessions is a single-digit percentage, and we would not present that as a benchmark for anyone else — a B2B catalogue for a specialised product self-selects its audience heavily, and the same ratio on a consumer site would mean something completely different. What matters here is that roughly half the traffic is coming from search rather than from the company telling people the address, which is the part a website is supposed to add.

The reason we publish these at all is that “increased leads by 340%” is the standard currency of agency case studies and it is almost always unfalsifiable. A percentage with no baseline, no timeframe and no live URL cannot be checked. Two thousand five hundred sessions can be — and it is a small, ordinary number, which is exactly the point. This is what a well-built site does for a specialised manufacturer in its second year. Anyone promising you an order of magnitude more should be asked what they are measuring.

Measured

Month to month

Sessions: ~2,500 a month
From search: About half
Quote requests: 30–60 a month
Catalogue size: 9 families, ~120 entries
Infrastructure: One VPS behind Nginx

rounded, not rounded up

What we got wrong— signed off by the people who built it

The taxonomy should have been settled in week one.

We should have agreed the product taxonomy with their sales team in week one — reshuffling families later touched every URL.

Here is why that is expensive rather than merely annoying. A product family is not a label — it is the middle of every URL on the site, the parent of every breadcrumb, the grouping in the navigation and the thing search engines have spent months deciding this site is about. Move a product between families and you have changed its address. Change enough addresses and you are writing redirects, re-checking internal links, and asking Google to re-learn a structure it had already indexed.

We took the taxonomy from the existing printed catalogue, which was reasonable and wrong. The printed catalogue was organised the way the factory thinks about its own production. The sales team, who actually field the enquiries, group the same products by the application a customer arrives with. Those two groupings do not agree, and the sales team's version is the one that matches how people search.

The fix costs one meeting if you hold it before any code exists. Now we put the product hierarchy in front of whoever answers the phone during discovery, and we ask them to sort it — not the founder, not the brochure. It is the single cheapest hour in a catalogue build, and it is why the tooling catalogue we built next started from how buyers search rather than from how the product is made.

What a build like this costs— and what moves the number

Seven weeks, and where they went.

We quote one fixed number after discovery rather than publishing a price list, for reasons set out on how we cost a build. What is useful to share is where the seven weeks actually went, because that is what any quote for this kind of site is made of.

Roughly a week went into discovery and the product hierarchy — and, as above, it should have been a week and one more meeting. Design and front-end build took the largest share. Catalogue data entry and checking 120 technical entries is its own line item and is routinely underestimated: someone has to read every specification against the source, and that someone should not be a developer guessing. The quote workflow, the database, the deployment and the search structure took the rest.

If you are pricing a comparable project, the variables that move it most are catalogue size, whether your specification data already exists in a clean spreadsheet or has to be typed out of a PDF, and how many people have to approve a page before it ships. None of those are technical. All of them are decided before a line of code is written.

Cross-reference

Filed alongside

See also

Have a catalogue that
nobody can find?

Send us the product list. We will tell you what the structure should be before we tell you what it costs — and the first answer is free.

Book a scoping call Read the other records

no commitment required · we reply within 24 hours

Manufacturing company website design:
smmtools.co.in

A catalogue is not a brochure.

Three calls that shaped the build.

Catalogue pages are statically generated and rebuilt on publish, not rendered per request.

The quote request writes to Postgres first and sends email second.

No CMS. Catalogue content lives in typed data checked into the repository.

What it does in a normal month.

The taxonomy should have been settled in week one.

Seven weeks, and where they went.

Filed alongside

Website development in Gurugram

A 180-SKU B2B catalogue

How we cost a build

All case records

Have a catalogue that
nobody can find?

Manufacturing company website design:smmtools.co.in

A catalogue is not a brochure.

Three calls that shaped the build.

Catalogue pages are statically generated and rebuilt on publish, not rendered per request.

The quote request writes to Postgres first and sends email second.

No CMS. Catalogue content lives in typed data checked into the repository.

What it does in a normal month.

The taxonomy should have been settled in week one.

Seven weeks, and where they went.

Filed alongside

Website development in Gurugram

A 180-SKU B2B catalogue

How we cost a build

All case records

Have a catalogue thatnobody can find?

Manufacturing company website design:
smmtools.co.in

Have a catalogue that
nobody can find?