How does this site work behind the scenes? How is it built? How does a text file become a web page? How were design decisions made?
Colophon
The professional name for this type of page is a ‘colophon’. It’s used on websites to explain how the site was built, what makes it work technically, why it looks the way it does, and how the decisions that led to the final visual and behavioral result were made. What’s happening under the hood, broadly speaking.
How the Site Is Built
The site is built on Quartz — a fast, batteries-included static site generator [SSG] that converts Markdown files into a live website, heavily styled and customized beyond recognition.
The process itself is fairly simple:
- As of now, I write and edit in Notion.
- I export the page as a Markdown file [.md]
- I save the file in the site’s content folder [content /he or /en]
- Every change is tracked by Git — I run git add > git commit > git push
- All files are stored in a repository on GitHub — which serves as the site’s central code repository.
- At this point, Cloudflare Pages detects the changes and automatically triggers Quartz.
- The magic happens — Quartz converts the Markdown files into static HTML.
- The site goes live via Cloudflare, and within minutes the content is live on the domain.
No CMS, no database, no admin interface, no cookies, no aggressive tracking — everything starts and ends with text files converted into a static site. Here’s also a short flow diagram, because why not:
Notion → Markdown file → git push → Git repository → GitHub → Cloudflare Pages → Quartz build → Live Website
A Few Important Notes:
A. Quartz generates a static site. This is the best option from every angle for a site of this type — static build means no pages are generated at browse time, and there’s no database or server rendering pages in real time — every page is pre-built and ready to load, which makes the site exceptionally fast.
B. The URL of most pages on the site contains the language, type, and name: /{lang}/{type}/{slug}. This structure is locked in and was chosen carefully [after way too many hours of research spread over several days] with the goal of surviving long-term. Any future changes will require manual 301 redirects.
C. In terms of tracking, the site currently uses no analytics tools. If I add one in the future, I’ll most likely use Plausible Analytics, which is natively supported by Quartz. It’s a privacy-focused analytics tool that uses no cookies, doesn’t track users across sites, and provides only basic traffic data.
General Decisions
1. The Original Vision
I initially built the site on WordPress. I quickly realized it wasn’t the right path. I stopped everything and, before choosing a different technology, I wrote out at length every technical requirement I could think of. Here’s a short edited list of what I wrote at the time. I wanted the site to be:
- Public
- Comfortable to read
- Especially fast
- Minimalist and clean
- Easy to write and publish
- Dark mode and light mode
- Smart link hierarchy
- Comfortable to use on desktop, tablet, and phone
- Pop-ups for external and internal links
- A graph displaying connections between pages visually
- Something that doesn’t require me to fight the tool in order to write
- Full control over design and personal customization
In addition, I wrote about the types of content I wanted on the site — several core pages including:
A library containing books, articles, images, podcasts, films, series, and other files. Pages for questions, quotes, notes, and ideas. Entries for people, self-experiments, and detailed in-depth research articles.
In terms of categories and tags, my goal was:
To build a smart, strong hierarchy that would hold up long-term on a single website that brings everything together in a clean, convenient way — both for publishing content and for the reader. UX/UI that is nothing less than pixel-perfect on both mobile and desktop. Supporting 2 languages: English and Hebrew, with the potential for additional languages in the future.
2. Why Quartz?
It took me far longer than I’m willing to admit to find the current stack — decision-making is not my strong suit. This time I allowed myself to take my time, since this is a decades-long project.
Even before I stumbled upon Quartz, I evaluated several options including: WordPress, Ghost, Astro, Hugo, GitBook, Obsidian Publish, Digital Garden, Jekyll, Eleventy, and more. Fortunately, at that point I had a general picture of how the site should look at a high level. After research and building many pros-and-cons tables with Claude Opus 4.7, and leaning on what’s described in the first section of the original vision, I managed to narrow down the options.
At that stage the choice became fairly clear — I realized that Quartz meets the vast majority of my requirements and wishes right out of the box, to a rather extreme degree honestly. I have no words to express how grateful I am to Jacky Zhao for creating this project and releasing it as open-source. Thank you, dear stranger! To truly understand how significant that moment was for me, here’s a short lightly-edited excerpt from something I wrote to myself after discovering it:
I’m in the shower writing two days later
I just want to remind my future self of the feeling from that night [the day I discovered the concept of digital gardens in more depth] — more specifically, after spending an entire weekend building non-stop in WordPress and feeling it wasn’t going to work out, terrible frustration.
Luckily I ‘stumbled upon’ Quartz — exactly what I was looking for, a kind of eureka moment and extreme euphoria I hadn’t felt in years… a truly fucking amazing feeling.
The feeling of understanding just how meaningful this project really is to me — even a life mission at some level. How it connects so many areas of my life at once — exactly what I was always searching for and wanting…
The fit was extreme — this is exactly what I wanted. Exactly. This is exactly… a smile that didn’t leave my face
…I got in the car for a drive and was just in euphoric astonishment for a few minutes.
3. Design and User Experience
The site is built around one central idea: a fluid and comfortable browsing experience that enables exploration, reading, and wandering between different pieces of content. The goal is that both a reader arriving for the first time and myself as the site’s creator can navigate it easily, quickly, and intuitively — whether reading an article on mobile, finding related content through the graph or sidebar, or randomly moving from one page to another.
I’ve tried to reduce noise as much as possible. Design is a particularly essential element for me, especially in a project of this kind — typography, spacing, color palette, navigation, interface behavior — all of these play a significant role in the reading experience and in the sense of wandering I’m aiming for. All of these are meant to serve the content — they are an inseparable part of it.
3.1 Typography
In Hebrew:
- Headings: Open Sans Hebrew Condensed
- Body text: Noto Sans Hebrew
In English:
- Headings: Barlow Condensed
- Body text: Inter
For code: IBM Plex Mono
3.2 Colors
The site includes dark mode and light mode. Dark mode received significantly more attention — it’s simply the way I use the site myself. By the way, who are you people who prefer light mode? Why?
The background is not pure black but a very dark blue. The text color is also not pure white but carries a slight blue-gray tint — this is less aggressive on the eyes over time and, to my understanding, the approach recommended by writers in the field and UX/UI experts — pure white on pure black is not ideal and causes eye strain over time.
3.3 Two Languages
I write naturally in both Hebrew and English. A large portion of my private notes were written in English. A large portion of new thoughts are written in Hebrew. Some are mixed. Rather than choosing one language, I decided to let both coexist. Not every idea will appear in both languages, though I’ll aim to eventually translate everything.
Additionally, English opens the site to the global reader — which is itself an enormous advantage. Hebrew preserves the natural tone for a Hebrew-speaking Israeli audience. The site is built with a separate build for each language: stamadam.com/he for Hebrew, stamadam.com/en for English. Each language is independent — fonts, directionality, content.
In most cases, a page will be written in one language first and then translated. I don’t see a need for manual translation — it will be done using a language model, and I’ll aim to keep the writing style as faithful to the original as possible, after which I’ll go over the text to make targeted adjustments.
3.4 Mobile
The site was carefully adapted for comfortable reading on mobile — most people will likely encounter the site while browsing on their phone, which makes this especially important. That said, despite the mobile adaptations, I do recommend the enthusiastic reader use the site on a computer. The experience of the site, of reading, and of browsing to explore and navigate between articles is far more enjoyable and comfortable.
On mobile, you’ll find 2 buttons at the bottom of every page — one on the right and one on the left. The first opens the sidebar containing the main content explorer and the graph. The second gives access to the six most useful functions: language selection, theme toggle, site search, table of contents, jump to a random page, and backlinks.