Why this site is built this way: simplicity, two languages, a corner of my own

The first step in building a site often looks like choosing a tool. But a few decisions come before the tool, and the tool is their consequence. This site’s structure rests on three of them: staying simple, being bilingual from the start, and keeping the content in a corner of its own. This post explains what those decisions mean and what they cost. A separate post covers the technical details; here the reasoning comes first.

Simplicity: the value of the work not done

Simplicity is often used as a pleasant-sounding adjective, but here it has a more concrete meaning: minimizing the number of parts that have to be run and maintained. This site is made of static files. There is no database, no application server and no session handling. When a visitor asks for a page, a file prepared in advance is delivered.

That choice has four consequences. The first is a smaller security surface: a site with no login form that collects no user data has fewer parts open to attack. The second is resilience: with no running code, there is less that can crash. The third is cost: according to Cloudflare’s pricing page, requests to static assets are free and unlimited (as of 14 November 2026), so hosting stops being a line item. The fourth is speed: a ready file arrives faster than a page that has to be generated.

Simplicity shows in the design too. The typefaces are served from the site itself, so no connection to a third-party service is made for fonts; the repository holds packages for the Inter and Source Serif 4 typefaces, and subsets that contain only the characters Turkish needs are used. Basic functions such as navigation, the language toggle and pagination work as plain links; JavaScript steps in only for supporting jobs such as search, copying a link and highlighting in the table of contents. The rule is to ask, before adding something, whether things would work without it.

There is a cost as well. Simplicity means giving up the comfort of a ready-made product. Features such as a comment section, subscriptions and user accounts are not here, and adding them later would be a change of structure, not a setting. That is deliberate: the site’s job is to be read, not to collect interaction.

Two languages: a feature that is not added afterwards

The site was designed as Turkish and English from the start. The reason is simple: when multilingual support is bolted on later, it easily turns into a patchwork. URLs, labels, search, feeds and page titles are all affected by language. Thought through from the beginning, these parts are fed from a single structure.

In practice the rule works like this: every post is two files, with the same filename in the tr and en folders. That naming makes finding the counterpart trivial. The Sveltia CMS docs describe this layout as the multiple_folders structure: each language has its own folder, and the path contains the language folder. A missing translation is no separate category either: if a Turkish post has no English file, the content check shows it as a warning and the post can still be published. Translation is therefore not mandatory, but its status is always visible.

Search respects language too. According to the Pagefind docs, a separate index is built for each language by reading the page’s lang attribute, and a Turkish page is searched only among Turkish pages. The two languages do not mix in the same search box.

The cost of being bilingual is plainly labour. Every post is written or adapted twice, and making the second version read as something other than a translation takes separate editorial attention. The English version is thought of not as a word-for-word translation of the Turkish but as an adaptation that carries the same facts and the same argument. In return the site does not close itself to people who read only one of the languages, and a reader who uses both does not have to rediscover the same content twice.

A corner of my own: owning the content

The third decision is that the content lives in a space of its own, not on someone else’s platform. Text written on a social network or a publishing platform depends on that platform’s rules, its algorithm and its lifespan. A platform changes its interface, removes a feature or shuts down, and the posts can become unreachable with it.

On this site the posts are Markdown files in a git repository. The content collections described in the Astro docs validate those files against a schema, and if the schema is broken, nothing is published. That is the practical meaning of ownership: the content sits as plain text, every change has a history, and if a move to another tool is needed tomorrow, the files can be carried over as they are. The panel follows the same logic: Sveltia CMS is only an interface, and the content is in the repository, not inside it.

“A corner of my own” is not a claim of isolation. For a site to be read, found and shared by others, it needs outside services such as a domain name, a search engine and a hosting provider. The difference is that those services are replaceable: the domain is yours, the files are yours, and the hosting can move to any static file server. There is dependence, but no lock-in.

What do these choices leave out?

The three choices reinforce each other, and each leaves something out. Simplicity leaves out interactive features, bilingualism leaves out single-text effort per post, and ownership leaves out the ready comfort of a managed service. This is less a list of losses than a list of priorities: the site’s first aim is to be read, the second to last over the long term, and the third to keep its upkeep small.

A choice is not right or wrong; it either fits a purpose or it does not. For a multi-user, interactive product this structure would fall short. For a text-focused, single-author, bilingual corner it does a lot with few parts. The reasoning for building the site this way is exactly that proportion.