SS-WEB-00 · CASE STUDY #0 · THE OPEN FILE

How this site was built.

A web studio’s own website is the one work sample it can’t fake. So here’s ours — brief to launch, drafts and scores included, run on the same products, process, and checklist we sell.

The situation

A new studio has a proof problem: no clients yet means no portfolio, and most agencies solve that with borrowed logos and vague claims. We publish prices and checklists for a living — faking the portfolio was off the table. The only honest first sample was our own site.

The goal

Ship a site that passes our own published 14-point checklist, prove the process by documenting every pass — including the rough ones — and wire measurement from day one so the performance numbers publish themselves at launch.

What we did

Six passes, scored honestly. The 3/5 stays in the file.

Every design pass was gut-scored by the founder against one bar: would a skeptical buyer believe senior specialists made this? Low scores didn’t get buried — they got diagnosed. That’s the process working, not failing.

v1.0Direction locked: Confident ClarityThree directions considered; warm editorial won. Display typeface chosen by controlled taste test — two candidates, identical copy, single variable.DIRECTION SET

v1.3First full buildRight copy, right tokens — default layout. Verdict: too generic to prove design expertise.SCORED 3/5

v1.4“The Open File” recompositionThe site becomes its own annotated working file — struck-out agency clichés, spec callouts, an editorial ledger. Closer.STILL SHORT

v1.5“The Marked-Up File”The human second pass: highlighter, handwriting, tape, a pen circle on the recommended plan. Direction right, execution still short.SHORT OF BAR

v1.6“The Composed File”Structural recomposition, load choreography, full mobile expression — and a render-verification loop that screenshots every claim at three screen sizes before it ships.SHIPPED · 4/5

Why the checklist isn’t theater

Two bugs the process caught before you did.

Render verification means we screenshot and test every page state instead of trusting the code reads right. On this site, that step caught two defects that had shipped silently through an earlier pass:

Caught in render QA

The signature moment wasn’t firing

The hero’s strike-through animation — the brand’s visual thesis — was being silently overridden by a styling conflict. It looked fine in the code and never drew on screen.

✓ Fixed and verified at three screen sizes

Caught in render QA

The recommended price shrank

A rule meant to shrink the small “/mo” label was also catching the price itself on the featured plan — collapsing the most important number on the page to body-text size.

✓ Fixed — all three tiers display at full size

Neither bug survives a written checklist plus a screenshot. That’s the whole argument for the 14-point bar: quality you can verify beats quality you assert.

The result

Measured in public, at launch.

This page’s speed and accessibility scores publish automatically the day the site goes live — measured, not typed in. Until then, the slots below stay honest: empty.

—/100Performance, measured at launch

—/100Accessibility, measured at launch

14/14Checklist required to ship

Start your own file

Product: Web Presence Build — the same one on our price list
Process: Map → Build → Grow, documented at every step
Type system: Fraunces + Inter, chosen by scored taste test
Verified: Three screen sizes, motion off, scripts off

Reserved — client #1

The next case study on this page is a client’s — published with their measured numbers and written sign-off. Until then, this space stays empty. That’s the policy.

END OF FILE · SS-WEB-00 · yours starts with a plan

Your business could be file two.

Same products, same process, same checklist — pointed at your goals. It starts with a free written plan, yours to keep either way.

Get your free growth plan or see plans & pricing →