Multi-page B2B website — self-initiated demo · 2026
NewLab Systems
This is a self-initiated demonstration project. NewLab Systems is a real company in the Poznań area; the site was not commissioned by them and is not their official website.
I rebuilt the site of a molecular-diagnostics distributor as a design and front-end exercise, choosing a subject where the audience is technical and the credibility bar is high. It is seven hand-written pages sharing one stylesheet and one script, with a Polish/English toggle, a canvas hero animation and an interactive panel for exploring diagnostic test contents. There is no framework and no build step — the files are served exactly as they are written.
- 7
- Pages
- 2
- Languages
- 0
- Build steps
Objective
What the problem was
- Practise designing for a specialist B2B audience, where the reader is a laboratory buyer and the copy has to be precise rather than persuasive.
- Build a genuinely bilingual site — the buyers are Polish, the manufacturer is international — without reaching for a framework.
- Keep the whole thing serveable as static files, to see what that constraint forces you to get right.
My role
Everything: structure, visual design, copy in both languages, the front-end build, and the deployment configuration.
What I built
- Seven pages — home, products, an HPV test detail page, the manufacturer partnership, technology, about and contact — sharing a single stylesheet and a single script.
- A Polish/English toggle covering every string on the site, including chart and statistic labels, with the choice persisted in localStorage so it survives navigation.
- An animated DNA-helix particle field on the hero, drawn on a canvas element.
- An interactive multiplex panel that lets a visitor filter diagnostic categories and panels and see exactly which targets each one detects.
- The company brand mark rebuilt as an inline, transparent SVG so it stays sharp at any size.
- Deployment configuration that revalidates shared assets on every request and keeps internal working notes off the public site.
Screens
Tools
Front end
- HTML
- CSS
- JavaScript
- Canvas API
- Inline SVG
Approach
- No framework
- No build step
- Shared asset architecture
- localStorage
Deployment
- Netlify
- Redirect and cache-header rules
Challenges
The decisions worth explaining
One script for pages that do not share elements
Every page loads the same JavaScript file, but the helix exists on one page and the multiplex panel on another. The rule I settled on is that the script may never assume an element exists — every lookup is guarded and stands down when its target is absent. Without that rule, a single missing element throws and takes the navigation and the language toggle down with it.
A language toggle that survives navigation
On a multi-page site with no framework, the obvious implementation resets to Polish on every click, which makes the site feel broken to an English reader. Persisting the choice in localStorage and re-applying it on load is a small piece of code that is the difference between a working feature and a decorative one.
Shared assets and stale caches
The stylesheet and script keep the same filenames across deploys, so a returning visitor can sit on a cached stylesheet and see a half-updated page — which happened to me locally while building. The deployment config now revalidates those assets on every request. It costs a 304 and guarantees nobody sees a broken version.
Inlining versus sharing
The CSS and JS were originally inlined in each page. At roughly 63% of the file, that meant about 237KB duplicated across six pages, and six copies of every future change. Moving them into shared files was the right call, but it is what created the first two problems above.
What I learned
- A no-build-step constraint removes the safety net and makes you think about load order, caching and defensive lookups directly, rather than trusting a bundler to handle them.
- Configuration and documentation are part of the deliverable. The cache rule and the redirect that hides internal notes are as much a part of this project as the layout.
- Writing technical copy for an audience that knows more than you do is a research task first and a writing task second.
Source code
The repository is private. Happy to share it on request.