There are faster ways to build a website than starting with an empty file. I use modern tools when they make sense, and I have no moral objection to frameworks, systems or templates. A deadline is not improved by unnecessary heroism.
And yet, for certain personal and experimental projects, I still enjoy building from the basic materials: HTML, CSS, JavaScript and a little server-side logic where it is useful.
Starting close to the material changes the questions
When I work directly with the structure, I am forced to decide what the page actually is before I decorate it. What is content? What is navigation? What is interactive state? What belongs in the browser and what belongs on the server? What happens before the JavaScript arrives?
Those questions are easy to postpone inside a large system because the system has already made many decisions for you. That can be a major advantage. It can also hide the fact that your project does not need half of those decisions.
Building from scratch is not automatically better. It is simply more revealing.
Personal projects give me permission to experiment
burcakcinar.com is a good example. The site is not trying to behave like a normal portfolio template. Its orbit navigation, game section, live social integrations and draggable Fan Club are part of its identity. Starting from a highly opinionated portfolio framework would have required me to fight the framework before I could build the idea.
The older codebase also created the opposite challenge: I was not beginning with a blank technical history. I had legacy behaviour worth preserving and old assumptions worth replacing. Working close to the code made it possible to modernise selectively instead of rebuilding the site into something visually safer and conceptually weaker.
I like seeing where the weight comes from
Performance feels different when you can point to every dependency and explain why it exists. A large library may still be the correct choice, but I want that to be a decision rather than an accident.
The same is true for API calls, images, fonts and scripts. When the Work section loads Instagram data, I know why the request exists and why it is cached. When the X Fan Club handles thousands of profiles, I know why it needs batching instead of rendering everything at once. When the blog becomes a separate long-form system, I know why it deserves simple crawlable URLs rather than another animated overlay.
The architecture reflects the experience.
Scratch does not mean primitive
One misconception is that custom building means refusing modern practice. In reality, I care more about progressive enhancement, responsive behaviour, secure server-side credentials, semantic content, structured data and graceful failure precisely because I am close to the implementation.
If JavaScript fails, what remains? If an API is unavailable, can the user still understand the section? If the screen becomes very narrow, does the interaction survive? If Google needs to crawl a long article, does it have a real URL and meaningful markup?
Those are not glamorous questions, but they are often the difference between a visual demonstration and a working digital product.
The real reason is probably simpler
I still like the feeling of making the browser do something specific because I asked it to, not because a template had a setting for it.
That feeling connects directly to how I entered the web in the first place: experimentation, immediate feedback, curiosity and the occasional mistake that becomes a feature because it is more interesting than the original plan.
I do not think everyone should build websites from scratch. I do think every web designer benefits from understanding what exists underneath the systems they use. Knowing the material changes the way you design with it.
Sometimes the fastest solution is a framework. Sometimes the smartest solution is a CMS. Sometimes the right answer is a small custom page with exactly the code it needs and nothing else.
The useful skill is not loyalty to a tool.
It is knowing why you chose it.
Knowing when not to start from scratch
The freedom of custom building can become its own trap. If a project needs mature authentication, complex editorial workflows, large teams or a feature set already solved extremely well by an established platform, rebuilding everything personally is not creative independence. It is maintenance debt wearing a heroic costume. The visitor does not award extra points because the checkout was hand-coded in a dark room.
Professional judgement means recognising when the project benefits from custom architecture and when it benefits from an existing system. I enjoy writing direct code because it keeps me close to the material, but I do not confuse enjoyment with the objective. Sometimes the most responsible creative decision is choosing a boring, proven foundation and spending the saved time on the part of the experience that actually needs invention.
The projects where I choose the scratch approach are usually the ones whose interaction is unusual enough that the structure itself carries the idea. When the structure is ordinary, I am happy to let proven tools do ordinary work efficiently. Building from scratch is valuable to me because it preserves freedom where freedom matters—not because every wheel deserves another redesign.