Conversion-focused landing page — self-initiated prototype · 2026
Alucover
Built in my own time as a prototype. It is not Alucover’s official website, was not commissioned, and is unrelated to my installation job there — that role involves no software work.
I install aluminium pool enclosures full-time. That means I know the product, the questions customers actually ask on site, and the reasons people hesitate — so I built the landing page I thought the product deserved. It is a single self-contained file: one page, three languages, every image embedded, no external requests, no dependencies.
- 3
- Languages
- 158
- Translation keys
- 1
- Self-contained file
Objective
What the problem was
- Turn what I hear from customers during installations into the structure of a page — lead with the season-length argument, because that is the objection that actually decides the sale.
- Support Polish, English and German, since the product category sells across the border.
- Ship something that loads fast on a phone in a garden with poor signal, which is where a prospect is most likely to look at it.
My role
Everything: the commercial argument and copy in three languages, the page design, the illustrations, the front-end build and the deployment.
What I built
- A single-page site covering the seasonal argument, benefits, the product range, reasons to buy, the process, a gallery, FAQs and a quote request.
- A trilingual Polish/English/German toggle driven by a translation table covering 158 keys per language.
- Custom inline SVG line-drawings of each enclosure profile, with a human figure for scale, instead of photographs — they stay sharp, weigh nothing and read clearly at small sizes.
- Every photograph embedded directly in the page, so it makes no external image requests at all.
- Mobile behaviour handled explicitly: anchor scrolling that accounts for the fixed header, scroll locking behind the open menu, and safe-area insets for notched displays.
Screens
Tools
Front end
- HTML
- CSS
- JavaScript
- Inline SVG
- Embedded images
Approach
- Single self-contained file
- No dependencies
- Three-language content table
Deployment
- Netlify
Challenges
The decisions worth explaining
Three languages without a framework
Every translatable element carries a key, and one table holds all three languages. It keeps the copy in a single place rather than scattered through the markup, so adding German after the fact was filling a column rather than editing the page again.
Deciding what the page argues
The hardest part was not the code. The page leads with how much longer the swimming season gets, because that is the point at which customers on site stop treating the enclosure as a cover and start treating it as an extension of the house. Working with the product is what told me that; I would not have guessed it from a brief.
Mobile is where it will actually be read
A prospect looks at this on a phone, standing next to their pool. Anchor links that scrolled underneath the fixed header, a page that scrolled behind the open menu, and content lost under a notch were all real defects, and fixing them properly took a dedicated pass.
What I learned
- Knowing the product physically changes the copy. The objections I answer on the page are ones I have answered in person.
- Embedding assets and depending on nothing external is a legitimate engineering choice for a page this size, and it makes the result trivially portable.
- A translation table is worth building before the second language, not after — retrofitting the first one is the expensive part.
Source code
The repository is private. Happy to share it on request.
Next project
Stravo Media
The independent venture the rest of this work sits under — positioning, website, sales process and the internal system that runs it.