LP Factory — A Generation System for Financial Landing Pages
Design tokens → components → a single YAML brief generates financial landing pages. A fail-closed compliance gate is built in: the build itself fails if required regulatory disclosures are missing.
- TypeScript
- Vite
- Design Tokens
- Playwright
- vitest
Problem
Financial (insurance/banking) ad landing pages consist of static markup, a consultation form, mandatory regulatory disclosures, and separate desktop/mobile builds. In practice, each variant (e.g., a product targeted at women) is a page manually duplicated from the last, disclosure text is hardcoded into images, and accessibility, performance, and duplicate-submission prevention are easy to neglect. In fact, one reference page was found missing its privacy-policy link — exactly the kind of incident this invites.
Approach
I worked through two live financial landing pages (insurer A, digital bank B) in the order dissect → rebuild → improve.
- Design tokens first. Colors, typography, and spacing were extracted into tokens, and every component (hero, benefits, consultation form, info accordion, FAQ, disclosure footer) was made to consume only tokens.
- Brief YAML → LP-generation CLI. Variants are generated automatically from a single overrides block (default gender, product name). The dissection step proved that the original “variant” pages were, in effect, just data substitutions — this structures that fact into the pipeline.
- Compliance as code. The regulatory approval number, privacy policy, and disclaimer text are all data slots. If any of them is missing or expired, generation itself is blocked (fail-closed). The system catches what a person forgets.
Results (measured)
| Metric | Rebuild (desktop) | Rebuild (mobile) | Original (desktop) | Original (mobile) |
|---|---|---|---|---|
| Lighthouse performance | 100 | 100 | 97 | 73 |
| Accessibility | 100 | 100 | 68 | 80 |
| SEO | 100 | 100 | 82 | 82 |
| LCP | 0.2s | 0.8s | 1.0s | 5.1s |
All 10 defect categories found in the original (missing headings/alt text/labels, no duplicate-submission prevention, disclosure text hardcoded into images, and more) were resolved. A performance ≥90 / accessibility ≥95 gate is built into the pipeline to block regressions.
The very site you’re looking at right now was built on the same principle (tokens → components → performance gate) — proof that the methodology carries over.
Limitations and failure modes
- Judging the legal adequacy of the original brand design and disclosure text is out of scope for this tool — the system only blocks missing or expired disclosures; whether the wording is legally correct remains a matter for humans and the regulatory body.
- The production backend for the consultation form (personal-data storage) belongs to company infrastructure; this tool only covers the front-end contract.
- The rebuild’s metrics are local measurements taken under identical content and conditions; numbers may differ in a production environment (third-party scripts, etc.).
What I learned
Performance, accessibility, and compliance aren’t kept by “let’s be careful.” Turn them into a gate, and they hold. Converting a failure into a build failure, instead of trusting human attention — that was the most valuable pattern in this project.