There is a trade every business with a product catalog has been told to accept. A static site is fast, secure, and nearly impossible to break, but nobody can edit it without a developer. A CMS platform is editable, but now you are renting your website, carrying plugin weight, and hoping the whole stack stays up. We built a site that refuses the trade.
Polymer Nation is an American industrial coatings manufacturer: epoxies, polyaspartics, polyureas, urethanes. Their catalog runs 109 products across 25 engineered systems, and the sitemap carries 242 URLs. The team needed to fix a spec, swap a photo, or retire a product without filing a ticket and waiting on a deploy.
Rebuilding their site as custom code bought them speed and ownership, but it raised the question every static-site skeptic asks: how does a coatings manufacturer keep 109 products current without becoming a software company?
The architecture in one paragraph
The site ships with a static snapshot of the entire catalog baked into the build. That snapshot alone is a complete, working website. On top of it, the catalog pages read live rows from a hosted Postgres database at request time, and the client edits those rows through our client portal. The live data overlays the static data. That is the whole trick.
And the catalog is not small. Beyond the 109 products, the site carries 25 engineered systems, 53 application pages, 14 markets, 117 color swatches, and 114 technical documents, all typed data feeding the same templates. The editable layer sits on top of a structure that was engineered once and holds.
When someone on their team saves a product, the portal calls a secret-authenticated revalidation endpoint on the public site. That endpoint refreshes exactly the pages the product touches, by cache tag and by path, and the change is live within seconds. No redeploy. No waiting on a build. No cache-purging ritual.
Designed to fail toward working
The part we care about most is what happens when things go wrong. If the database is unreachable, or the environment keys are missing entirely, the catalog quietly falls back to the static snapshot. The comment in the catalog code says it plainly:
“So the site never breaks.”
— a comment in the catalog loader
That failure mode is worth spelling out. Most CMS-driven sites have a single point of failure: the CMS. Here, the worst case is a catalog that is a few edits behind. Never a down page. Never an error screen in front of a customer.
- Edits appear on the live site in seconds, not on the next deploy
- A database outage degrades to a slightly stale catalog, never a broken page
- There is no CMS subscription, no plugin surface, and no platform lock-in
- The same data-cleanup rules run on live rows and on the fallback, so quality holds in both worlds
The unglamorous work that made it real
Getting there meant moving the client off their old platform for real. We migrated 691 media files, 136 MB in all, off the old CDN and onto first-party hosting, so nothing on the new site depends on a service they were leaving behind.
The product descriptions carried baggage too. 59 of the 109 began with a literal "Product Overview" label left over from the old site's template. We wrote a cleanup layer that strips those artifacts, and we applied it to both data sources, so the fix holds whether a page renders from the database or from the fallback.
Products carry structured fields for specs, markets, documents, and images, plus a status flag, so a draft never leaks onto the live site and a discontinued product exits cleanly.
Editable did not cost fast
The reflex assumption is that live data makes a site slow. It does not have to. The rest of the site stays fully pre-rendered: markets, applications, systems, and news pages are all built as static pages, and only the catalog routes render per request so edits show up immediately.
The receipts: the live site scores 100 in every PageSpeed Insights category on desktop, and on mobile it holds 98 for performance with straight 100s everywhere else.
What editing actually looks like
The client signs into our portal, opens the product, edits the fields, and saves. The public page updates within seconds. That is the entire workflow, and it is also the entire training manual.
Compare that with the alternatives. A hosted website builder gives you editing but takes the code, the speed, and a monthly bill. A traditional CMS install gives you editing plus a plugin surface to patch forever. A headless CMS subscription gives you editing and another vendor between you and your own content. This gives the client editing, and it gives them nothing else to maintain.
Our clients should not have to pick between owning fast custom code and being able to change their own content. The portal gives them the editing. The static snapshot gives them the floor. And the floor is a working website, always.
