SeTRoX.com: a home for my writing and projects

A place to publish as well as a place to show work

I did not imagine SeTRoX.com as only a page containing professional titles and a few links. I wanted a developing personal space for writing, ideas, projects, and thoughts from everyday life. A computing journey beginning in 1986 could sit alongside present-day interests in technology and AI. A game project and a personal essay would not have to exclude one another. The main question was therefore broader than creating an impressive home page: How can a website feel personal, remain readable, and be manageable as its content grows? Those needs had to be considered together.

That intention affected design and infrastructure together. Articles, project return paths, phone navigation, and a content panel belonged to the same experience. The site is a personal blog and showcase, rather than a place to collect paid service requests. Technical capability alone does not determine which functions belong in its scope.

Put readability at the center of visual design

Strong typography, generous space, and animated 3D entrances were useful visual references. Looking at references did not mean copying their compositions or assets. SeTRoX needed its own identity, portrait treatment, and reading layout. Reviewing early designs also revealed problems such as small text, dark presentation, and unclear routes back from detail pages. That feedback showed why design could not stop at the opening screenshot. A site can make a strong first impression and then lose its visitor on the second page. The first moment cannot carry the entire experience by itself.

Home, archive, profile, article, and project detail pages therefore need to be considered together. Navigation should help a visitor find their way, text should remain readable beside an animated scene, and returning from a project should be understandable. MDN's accessibility resources provide a reference for semantic structure, keyboard use, and text alternatives. This is not a claim of certification against every accessibility criterion. It explains why readability and ordinary usability need a place in the design decisions from the start, instead of being treated as a finishing decoration.

One application and two language domains

The current public structure uses two addresses: setrox.com for English and setrox.com.tr for Turkish. The domain determines the language; public home and detail paths do not display /en or /tr prefixes. This does not mean two independent applications were created. Both use the same source files, Next.js application, PostgreSQL database, and shared Payload administration panel. The arrangement provides language-specific pages without duplicating the design and content model in separate systems. Visitors see an address in the appropriate language, while the operating structure remains one application rather than two diverging copies of it.

Language switching does not have to send everyone to the other domain's home page. Where an article has both versions, its translation relationship can open the corresponding page. Turkish and English are managed as separate texts linked by a translation group. Publishing in one language does not automatically mean the other version is ready. This distinction matters for substantial content: translating a heading is not enough. Summaries, links, image descriptions, and search metadata should also match their language. A shared system makes coordination easier, but it is not an excuse to copy content without reviewing it.

Next.js as the frame for content and interaction

Next.js and React provide the frame for articles, archives, profiles, projects, and interactive components. Each layer needs a clear role. Reading an article should not require interacting with the entire 3D scene. The visual signature can support the content while text and navigation remain meaningful on their own. Organizing those different needs in one application was the purpose of this technical choice.

The official Next.js self-hosting guide is a reference for running the application outside a managed hosting platform. SeTRoX is deployed through Docker and Dokploy in the existing server environment. That is a choice matching the infrastructure available here, not a claim that every personal site should use the same method. Local development, production build, and live deployment are checked as distinct stages. A page opening on my computer is not by itself evidence that a visitor's HTTPS address produces the same result with the correct content and assets.

Payload and a visual panel for more than articles

A visual editor was part of the initial requirement. I can have articles prepared with an assistant, but should also be able to manage headings, text, media, and site information through a browser. Payload CMS was included for that reason. Articles and projects have their own records, while shared information such as home-page and profile text lives in site settings. This separates content work from code work. Adding a paragraph should not require rebuilding the design. A different 3D model or component behavior, on the other hand, remains development work rather than an ordinary content field.

The rich-text editor is based on Lexical. Headings, paragraphs, links, selective bold emphasis, and body images belong to that publishing flow. The official Payload rich-text documentation provides a reference for the editor structure. Saving a record and publishing it are separate decisions, too. Drafts and previews are not treated as public publication. Language, dates, and the publication state of media need checking. A well-composed article does not automatically establish that all those publishing details are correct. The panel gives them a place to be reviewed alongside the prose.

Keep data and media independent of application updates

The database stores articles, projects, settings, and translation relationships. Media is held in persistent storage as well. The important principle is not restarting the content when deploying a new application version. Code may change while the owner's edits and uploaded files remain. Backups therefore involve more than copying source code. Database and media are considered together, encrypted, and copied to a separate Mac folder. Having a backup file and being able to restore it correctly are still separate questions. A reliable archive requires attention to both the stored information and its eventual recovery.

Initial content must not overwrite owner edits on deployment. New features need upgrades compatible with existing data, and image-path changes can affect published articles. Preserving identities, slugs, and relationships protects saved links and archive continuity. Growth should add useful capability while keeping earlier publications in place, rather than quietly resetting the work already stored.

A live 3D layer that supports the site's identity

The home-page 3D experience is rendered live with Three.js. Pointer movement, touch, and motion preferences can influence the visual experience. It is not a still Blender image being described as a moving scene; it is an interactive browser layer. Static visual production can also be used for article covers and supporting illustrations. The two forms have different jobs. Describing the source and behavior accurately matters. A render is an image artifact, while a live scene is software that also needs interaction and performance checks in its actual environment.

Visual richness should not push the text into the background. Reduced-motion preferences, scene pause controls, and suitable fallback presentation help maintain that balance. Theme and accent choices can also change the site's personal feel. Instead of demanding a new effect in every section, ask what the existing motion contributes. The same principle appears in the AI collaboration workflow: choose the tools and features that serve the goal rather than every available possibility. The scene should be a strong visual signature while allowing the visitor to read, move through the site, and find the content they came for.

Public reading and private administration need different boundaries

The public blog should be readable; its administration area needs a different access boundary. Cloudflare is part of the infrastructure used for site traffic and management access. The personal contact form uses Turnstile verification. The email address is not published in the general page source, and messages are read in the private panel. The form is for personal correspondence and site feedback, rather than collecting commercial service requests. Its presence does not change the site's purpose. The interface wording and the behavior behind it need to maintain the same scope as the rest of the site.

The official Cloudflare Turnstile server-validation documentation explains checking verification results on the server. A visible verification widget alone does not solve every spam problem. Access rules, form checks, and rate limits need to be considered together. It would be misleading to promise perfect security or no unwanted messages ever. The aim is to reduce unwanted automated submissions and separate private functions from public content. When those controls change, their live behavior needs its own verification. Security settings and an attractive contact section are different parts of the work.

Make search information match the actual publication

Page titles, descriptions, canonical addresses, language relationships, sitemaps, and RSS should reflect the same publication state. After the move to clean domain-based URLs, navigation and sharing links use those addresses too. Real articles are prepared as indexable publications; administration and private previews are not general search destinations. I do not regard SEO as merely adding keywords. Correctly describing a page, linking relevant material, and preparing content a visitor can actually use are editorial responsibilities as well as technical ones. The metadata should explain what the page truly contains, rather than promise a different subject.

Google's people-first content guidance is a useful reference for why a word count is not the objective by itself. SeTRoX's preference for longer articles is an editorial decision to explain topics properly, not a mandatory Google threshold. A cover image also does not meet every article's visual need. Sources, examples, and body diagrams can add useful depth. Submitting a sitemap does not guarantee indexing or rankings; crawling and evaluation are separate search-engine processes. Technical preparation and content quality need to support one another without being treated as interchangeable achievements.

A personal space that can keep developing

The real project pages currently make room for Rivunox and SeTRoX.com. Later work can be added without presenting future ideas as finished products. Writing does not have to remain exclusively technical, either. Personal thoughts, films, and everyday life can belong to the same identity. That variety does not require separate products for every topic. A shared publishing model, understandable navigation, and correct content relationships provide a base for growth. A new section becomes useful when it has a real purpose and material to contain, rather than merely making the menu longer.

I see the site as an editable archive. A strong first impression matters, while readable articles and easy navigation provide lasting value. One application and panel make growth manageable; two domains give each language its own place. The 3D scene adds a personal signature. A home for writing and projects should grow without losing its identity, data, or purpose.