I could have used a template, replaced the text & had a portfolio online much faster. That would have solved the "I need a website" problem, but it would have skipped most of the part I actually wanted to learn.
I wanted Shimori Cyber to become both a public record of my technical work & a real environment for practicing HTML, CSS, Git, GitHub, Cloudflare, DNS, UI/UX & deployment.
That means the rough parts are useful too. The broken mobile layout, duplicated navigation, images cropping incorrectly & pages that technically loaded but looked awful were all real problems I had to diagnose.
Build the portfolio instead of only filling one in, then document enough of the process that the site itself demonstrates technical growth.
1. Why I kept it simple
The site is plain HTML, shared CSS & a small amount of JavaScript. I considered whether I needed a framework, but right now I actually like that the fundamentals are exposed.
If a layout breaks, I have to understand the HTML structure & CSS responsible. If a path is wrong, I can see the path. There is less abstraction between me & the browser.
That is useful while I am deliberately practicing UI/UX & front-end fundamentals.
2. Building a design language instead of random pages
The first versions were much more inconsistent. A card might look good in one section but not belong anywhere else. Buttons did not always match. Some pages felt like the Shimori brand while others looked like default HTML.
The direction became much clearer once I treated the site as a design system: dark charcoal backgrounds, purple & muted gold accents, Japanese-inspired visual elements, consistent spacing, typography, cards, filters & article layouts.
The point is not to make every section identical. It is to make them feel like they came from the same place.
3. Git changed how safe experimentation felt
Git was important because I am still learning this workflow. If I am afraid to touch something because I might destroy the working site, I am going to learn much more slowly.
Version control means changes have history. I can inspect what changed, commit working milestones & recover when an experiment goes badly.
GitHub then becomes more than storage. It is the source the public deployment follows.
4. GitHub to Cloudflare Pages
The production site is deployed through Cloudflare Pages from the GitHub repository. That gives me a straightforward workflow: update the project, push the change & let the deployment system publish the new version.
The custom domain adds another layer. DNS, or Domain Name System, is what connects a human-friendly name like shimoricyber.com to the service hosting the site.
Working through that setup was useful because it connects front-end development to actual Internet infrastructure. A website is not just an HTML file. Somebody still has to resolve the domain, establish HTTPS, serve the files & deliver them to the browser.
5. Mobile taught me that "works on my screen" means very little
One of the biggest lessons was how quickly a desktop layout can fall apart on mobile. Navigation that fits perfectly at 1800 pixels can overflow. Large typography can dominate the entire screen. Images can crop around the wrong focal point. A desktop side panel can become useless on a phone.
I also ran into a particularly confusing case where mobile appeared to be opening older-looking content while desktop showed the newer layout. That forced me to look at links, page paths, deployment state & caching instead of assuming the browser was somehow randomly wrong.
Responsive design is not making the desktop page smaller. It is deciding what the interface should become when the available space changes.
6. The content needed a design system too
The first writeup page made this painfully obvious. The link worked, the HTML loaded & technically the task was complete. Visually it looked like a raw document with almost no connection to the rest of the site.
That was a good reminder that technically functional & professionally usable are different standards.
The article format now has a branded hero, readable content width, author information, section navigation, callouts, code blocks & consistent project/writeup navigation. More importantly, I locked that structure so future articles do not slowly drift back into random formatting.
7. Assets need to be designed for their actual job
I also learned this with the icon pack & project images. A large composite image can look great as a concept sheet & still be terrible as a source for tiny UI assets.
Icons need clean boundaries. Project images need a predictable aspect ratio & focal point. Logos need transparent versions & correct sizes. A visual asset should be created for where it is going to live, not just cropped out of something that happened to contain it.
8. The workflow is becoming the real project
The website now has a fairly simple loop: make the change locally or through the repository, inspect it, commit it, push it, let Cloudflare deploy it & then test the actual public result.
When something fails, I want to understand which layer failed. Is the HTML wrong? Is CSS missing? Is the asset path wrong? Did GitHub receive the change? Did Cloudflare deploy it? Is the browser showing cached content?
Breaking the problem into layers is far more useful than randomly changing things until the page looks different.
If a system has several layers, troubleshoot the layer that actually failed instead of changing all of them at once.
9. What comes next
The site still has plenty of room to improve. I want stronger accessibility, better project imagery, more consistent mobile behavior, deeper case studies, stronger SEO & eventually a cleaner process for adding new content without manually repeating too much HTML.
I do not want to add complexity just to say the stack is more advanced though. If a static site continues to solve the problem well, that simplicity has value.
The website should show the process
Shimori Cyber is supposed to document technical growth, so I actually like that the website itself has become part of that story.
It has already forced me to work through design decisions, Linux tooling, Git, GitHub authentication, deployment, Cloudflare Pages, DNS, caching, responsive CSS & content architecture.
There is a big difference between knowing what those technologies are & having to make all of them cooperate on a public site. That difference is exactly why I built it this way.