Content-led pages that ship as static HTML to the edge. Fast first paint, semantic markup, and no client framework unless the page genuinely needs one.
Available for new projects Independent web engineering
Fast, durable websites and the interfaces inside them.
vzco.de is an independent practice building static-first sites, product interfaces, and the design systems that keep them consistent.
- Focus
- Sites and interfaces
- Engagement
- Direct, one project at a time
- Based
- Frankfurt, Germany
- Contact
- [email protected]
01 — Services
What I do
Four kinds of work, usually combined on the same project: the page, the interface inside it, the system behind both, and the proof that it loads quickly for everyone.
Typed, component-driven interfaces assembled from a real inventory — including the hover, focus, loading, empty and error states that often get skipped.
Tokens, type ramps and component rules written down, so the next page looks and behaves like the rest of the site without reverse-engineering it.
Keyboard paths, focus handling, reduced-motion support and Core Web Vitals work treated as part of the build, not as a separate audit at the end.
02 — Open source
Built in the open
There is no product catalogue here yet — the work lives in public repositories instead. Everything below is read from my GitHub profile when this page is built, so it is the real list, not a highlight reel.
03 — Process
How the work runs
Three stages, the same on every project. Each one ends with something you can open, read or deploy — not a status update.
01 / 03
Scope the skeleton
We agree on pages, states and constraints before any visual work. The page map, the content outline and the technical limits get written down, so the build has something to measure against.
- Page map and content outline
- Technical constraints agreed
- Definition of done
02 / 03
Build in the open
Work lands on a preview deployment from the first commit. Every change can be opened on a real device at a real width, with the copy and the states checked in place rather than in a static mockup.
- Preview URL per branch
- Checked at 390 / 768 / 1440
- States reviewed in the browser
03 / 03
Ship and hand over
The site deploys from the repository, and the tokens, components and deployment steps are documented. The next change is a normal change, not archaeology.
- Deployment configured end to end
- Tokens and components documented
- Repository walkthrough
04 — Questions
Answers before you ask
The four things that come up first. Anything else is a short email away.
01 What does a project usually include?
Pages built from a shared layout and design tokens, every interactive state (hover, focus, loading, empty, error), a responsive pass at real widths, and the deployment configuration. Copy and imagery can come from you, or be structured together at the start.
02 Do you work inside an existing codebase?
Yes. A section, a design-system migration or a performance pass can be taken on without rewriting what already works. The first step is reading the repository and agreeing on the smallest useful change.
03 What happens after launch?
The site is built to be maintained: documented tokens, typed components, and a build that behaves the same way locally and in production. Handover includes a walkthrough of the repository and the deploy settings.
04 How do we start?
Send a short note with what the product is, which pages you need and any deadline. You get questions back and a written scope, and nothing is scheduled until that scope is agreed.
05 — Contact
Have something to build?
Send a short note about the product, the pages you need and any deadline. You get questions back and a written scope before anything is scheduled.