BVDNET · Own project
This site: separate blocks I can change one at a time
This site is built from separate blocks I can replace or test against each other one at a time. The homepage can change without the rest being rebuilt.
- Project type
- Own project
- My role
- Owner, design and development
- Status
- Website online
- Duration
- Ongoing since December 2025
- Team size
- 1
- The question
- A studio website needs to change as the work and priorities change.
- The result
- Replaceable sections and a dedicated environment for reviewing design variants.
The question
A studio site is never finished: work gets added, the emphasis shifts, a section turns out not to work. On most sites, every change means someone has to go into the code, with risk for pages that have nothing to do with it. That is why this homepage consists of separate blocks that I can replace or test against each other one at a time: eight blocks, nine variants. Changes take days instead of weeks as a result.
A studio's website is never finished. Work gets added, the emphasis shifts, a section turns out not to do what you hoped. On most sites, each of those changes means someone has to go into the code, and the risk extends to pages that have nothing to do with it.
That is exactly why sites go stale: not because the owner doesn't want to change anything, but because every change becomes a small project. I wanted a homepage where that is not the case.
Key issues
- Every change to one section can in principle affect the whole page
- Design choices are reasoned about instead of looked at
- Performance degrades gradually without anyone noticing
- Changes can't be rolled back without affecting the rest
Constraints
- Everything I do here, I must be able to explain to a client
- No invented proof: empty sections stay empty until there is something real
Project background
This is my own site, and I say so up front. There is no satisfied client behind it; what it shows is how I work when nobody is watching, and why I choose the same set-up for clients.
My approach and decisions
Every section of the homepage is a separate block with its own spec file. The hero, the services, the work, the process, the calculator: each is defined separately, including which variants exist and which one runs in production. Eight blocks, nine variants. Replacing one block doesn't touch the rest.
Looking at variants instead of reasoning about them. There is a separate workspace where I put variants side by side. A design choice you reason out in a table is a different choice from one you have seen.
Performance is a measurement, not a feeling. There are fixed budgets for load time and visual stability, and results are measured against a recorded baseline. If things get worse, the measurement shows it, not a gut feeling.
No fabricated proof. As long as there are no real client quotes, the testimonials section doesn't render at all, rather than showing something that looks like it. The same rule applies to numbers: what I can't show, I don't write down.
Technical details
Technologies used
- Next.js
- React
- TypeScript
- Sanity
- next-intl
- Vercel
- Playwright
- Vitest
What it delivered
The honest answer to ‘is it fast’: better, and not yet good enough. The measured load time of the largest element went from 7.7 to 4.9 seconds, a 36% improvement, and the time the page did not respond dropped by 81%. Those 4.9 seconds are still in the ‘poor’ category of the standard I measure against, and my own measurement file says so too.
I include it anyway, because this is exactly the kind of number most sites leave out. Beyond that, 992 unit tests in 92 files and 200 end-to-end tests in 17 files act as a safety net for changes.
- Load time of the largest element
- 36% faster, not yet good enough
- 7.7 seconds → 4.9 seconds
- Time the page does not respond
- 81% less
- 70 milliseconds → 13 milliseconds
- Automated tests
- Safety net for changes
- 0 → 992 unit + 200 end-to-end
Delivered
- 8 separate blocks with 9 variants
- Load time 36% better, blocking time down 81%
- 992 unit tests and 200 end-to-end tests
- Sections without real proof stay empty
Outcomes
- Replacing a section doesn't affect the rest of the page
- Design variants are looked at instead of reasoned about
- Sections without real proof don't render, instead of being filled with something that looks like it
- A drop in speed shows up in a measurement, not in a feeling
What I take forward
Lessons
- Blocks you can replace separately turn a change into a job of days; that is mainly a cost argument
- A design choice you have seen is a different choice from one you have reasoned out
- Publishing an honestly bad number is more credible than leaving it out
- Better an empty section than fabricated proof
The set-up with separate blocks is now the standard for client projects: it is why a site can grow with the business without being rebuilt every time.