01 · The disclosure
They are concept projects
The main web builds were not commissioned by the fictional brands they represent. I chose the ten. I set the premise for each one, chose the art direction, designed it, wrote the HTML, the CSS and the JavaScript, and published it with an account of how the build went — including the parts that fought back.
The names, business details, statistics and scenarios inside them are part of the design exercise unless explicitly stated otherwise. I keep that distinction visible because a portfolio should make it easy to tell what someone actually did.
One scope note, so this is not read as saying more than it says: it is about the ten web builds. The logo, identity and advertising work elsewhere on this site is a separate body of work and this page does not speak for it. I put no real client names anywhere on the site — a name you would have to take on trust is the opposite of what this page is for.
02 · Why build full projects?
A polished mockup can hide a lot
A complete site has to survive navigation, content, responsive layouts, forms, interaction, accessibility decisions and all the small states between the screenshots. A static frame in a design file never has to answer any of that. That is why I prefer complete builds — each one is a running page, not a picture of one.
What a finished build has to get right that a mockup doesn't
- Every width, not one
- A screenshot shows one viewport. A real build has to reflow at every width in between, including the awkward ones a mockup never has to answer for.
- The states nobody designs for on purpose
- Empty, loading, error, focus, hover, reduced motion. These only exist once something is actually running in a browser.
- Whether the interaction actually works
- A form that submits, an accordion that opens, a keyboard that can reach every control — these are either true of the code or they aren't, and a picture can't settle that either way.
A finished build can be opened, clicked through, resized and read — which is a different, more exposing kind of scrutiny than a mockup ever has to survive.
03 · What they show
What ten finished builds can — and cannot — prove
Each one is set below against its honest limit. Both columns are the same size, the same weight and the same colour, because shrinking the left-hand one is how a disclosure turns into fine print.
-
What they show
Visual direction. Ten sectors, ten art directions, no house style repeated twice — you can see how a concept gets treated before it becomes a page.
What they don't prove
Client communication. Nobody sent me a change I disagreed with, and no second decision-maker hated the colour. How I take feedback I did not want is not in this portfolio, because none of the ten could put it there.
-
What they show
Interface design and front-end implementation. Every decision across the ten is mine, and each write-up says why I made it and what I rejected first.
What they don't prove
Production traffic. Not one of the ten has taken real visitors, a real support request, or a Tuesday afternoon when something goes down.
-
What they show
Responsive thinking and technical problem solving. Each write-up says what broke, what it cost in hours, and what I would do differently — nothing here is under an agreement that would keep that private.
What they don't prove
Commercial results. Not one of them carries a revenue figure, a traffic graph or a conversion rate, and none of them ever will — there was nothing being sold and nobody to sell it to.
-
What they show
Accessibility decisions and consistency across a full experience. Ten forms, ten sets of interactive states, all built to the same practice.
What they don't prove
Real business outcomes. Nothing here had a real budget to run over or a real stakeholder to satisfy, so it can't demonstrate how that pressure gets handled.
Do not pretend otherwise — a portfolio of self-initiated work does not automatically prove the left-hand column just because it's easy to show. What it can offer instead is the thing on the right of this page: a measurement, with a date and a method attached.
Measured on this site. On 9 August 2026, npm run a11y — axe-core plus real key presses, 13 routes at 1440×900 and 390×844, reduced motion forced on, every page settled and fully scrolled before the run — returned 0 axe violations and 0 of 829 tab stops without a visible focus indicator.
In plain language: an automated checker found nothing to report, and every place the keyboard can land shows you where it is. Neither of those is the whole of accessibility, and neither is a certificate. They are two measurements with a date and a method attached to them.
04 · Different problems, different rules
Each one starts from a different premise, on purpose
Each project intentionally starts from a different fictional brief. A quiet hotel should not behave like a strength gym. A healthcare interface should not use the same visual language as a cyberpunk agency concept.
The point is not to repeat one personal style ten times. It is to see whether the design decisions can follow the idea — whether a change in premise actually shows up as a change in type, colour, rhythm and motion, rather than the same template wearing a different name.
- The premise sets the constraint
- Restaurant, hotel, clinic, gym, photography studio, skincare brand, brokerage, SaaS product, agency, education platform — each concept picks its own visual language before a single component gets built.
- The constraint has to survive contact with the build
- A design language that only works in a mockup and collapses the moment it has to hold real content, real breakpoints and real interaction hasn't actually followed the idea — it's decorated it.
- Ten voices, not one house style
- Editorial print, luxury heritage, Scandinavian calm, radical minimal, neo-brutalist, dark cinematic, organic botanical, precision dark, cyberpunk HUD, optimistic bright. No two of the ten share a visual language.
05 · The record
Read it, or run it — the choice is yours
What each case study documents
Each one covers the idea, the design constraints, the technical structure, what caused problems, and what I would keep. The live builds sit beside the explanation so the work can be inspected rather than simply described.
That is the whole method: state what a project is, build the entire thing rather than a slice of it, and write down what fought back along the way.
Ten self-initiated concepts, ten write-ups, ten live previews.
