I started with a growing need to create a space of my own: a place where I could write, structure my thinking, and present myself on my own terms. Not as a feed, not as a portfolio gallery, and not as a profile scattered across someone else’s platform logic.
I like writing. I needed a blog. But I also understood one critical thing from the beginning: for a visitor, the blog is secondary. First, the site has to answer simpler and more important questions. Who am I? What do I do? What kind of problems do I solve? How do I think?
That was the initial intention. The problem was that intention is not a product definition.
From need to ambiguity
For a long time, the idea existed only as a vague direction. I knew I wanted a personal site. I knew I wanted it to contain articles. I knew I did not want to depend entirely on platforms like LinkedIn, where old posts quickly disappear into the stream and become difficult to navigate even inside your own profile. Medium did not fit me either because of its split between free and paid access. Other platforms looked crowded, fragmented, or too generic for the kind of structured presentation I needed.
So the decision seemed obvious: build my own site. But very quickly I ran into a more honest problem. I did not yet know what exactly I was trying to build.
Acting on the need before defining the product guarantees the wrong solution space, regardless of the tool chosen later.
Searching for clarity through tools
At first, I tried to clarify the idea through exploration. I used AI heavily. Different tools helped with different layers of the problem.
- Perplexity helped me search for references, examples, and existing structures.
- ChatGPT and Claude supported brainstorming, reframing, comparison of options, and later helped with wording, code adjustments, and decision pressure-testing.
- Lovable was useful as a fast ideation layer when I needed rough directions for structure or generation-based experimentation.
In this case, AI helped me expand the search space, compare options faster, reduce friction in execution, and challenge my own assumptions. But it could not replace the one thing that was missing: a clear product definition.
I used it as a distributed working layer. Different tools handled different types of uncertainty: search, ideation, reframing, wording, and technical acceleration. The value was not in the tools themselves, but in assigning each one a role inside a process I controlled.
And until that definition existed, every tool was only helping me move faster inside uncertainty.
The false breakthrough
After a while, I thought I had figured it out. It felt as if I finally understood what I wanted. The form looked clearer. The direction felt real. I thought I had found the answer and could move directly into execution.
That confidence did not survive reality. I made a mistake that I know very well from professional product work: I moved into implementation before writing down proper requirements.
The irony was obvious. I have enough experience to know that no product should be built this way.
But here I was acting as both client and executor, and that combination created a predictable mess.
If I wanted to describe that situation honestly, it would sound like this:
The client gives no clear requirements, pays nothing, keeps changing direction, rushes the work, and never lets the executor rest.
That was the real turning point. The problem was that I had not yet fully translated desire into structure.
Why no-code did not solve the problem
Because I do not enjoy coding for its own sake, I spent around two weeks trying to find a no-code path.
This part was useful not because it gave me a solution, but because it exposed the limits of many solutions very clearly.
Some tools were fast at generating layouts, but the moment I needed predictable iteration, content structure, or controlled edits, the process became exhausting.
Constantly rewriting prompts is not a content workflow. It is unstable negotiation with a system that does not share your internal model.
Some tools looked attractive as visual builders, but fell apart once I considered the cost of maintaining a blog, adding structured pages, or scaling the site beyond a one-off landing page.
Some platforms offered huge ecosystems, but most of the functionality was irrelevant to my case, while the details that actually mattered still required workarounds, extra payments, or manual fixes.
Some were close, but imposed their own visual or structural assumptions. And if a product forces you to inherit someone else’s logic at the system level, then you are not building your own solution. You are adapting yourself to theirs.
At that point, I stopped evaluating tools only as a user and started evaluating them as products.
Evaluating a tool as a user asks whether it feels convenient. Evaluating a tool as a product asks whether it survives the work.
Looking at products through product logic
Once I switched from “what feels convenient” to “what actually works as a product,” the criteria became much sharper.
The metrics were not decorative vocabulary. They were decision filters. I was not choosing the tool that looked easiest in a demo. I was testing which product could support activation without confusion, depth without collapse, retention without re-learning, and progress without false conversion into short-lived output.
I started looking at activation. How quickly does the product help a person reach the first meaningful action? Can I understand where to start, what the system expects from me, and how to move forward without friction caused by noise, hidden logic, or scattered entry points?
I looked at engagement depth. Does the product support deeper work after the first steps, or does it collapse into distraction, UI clutter, and side paths? A strong first screen does not predict a stable third.
I looked at retention. Does returning to the tool feel natural, predictable, and cognitively stable, or does every new session require re-adaptation? If a product cannot preserve a workable mental model across repeated use, it slowly drains energy instead of supporting momentum.
I looked at conversion proxies. Does the product move toward a durable outcome, or does it merely create the impression of progress? It is easy to generate a page, a mockup, or a nice-looking block. It is much harder to move from that momentary result to a maintainable, scalable, structured system.
That product lens made the limits visible.
Some services solved the first 20% of the task but made the remaining 80% harder. Some reduced visible friction but increased dependency. Some promised simplicity but only delayed complexity until the moment changes became expensive.
And that led me to one of the clearest conclusions in the whole process:
Automation does not solve the absence of process. It amplifies it.
If the structure is undefined, the content model is unclear, and the outcome is not formalized, then automation only scales confusion.
Writing the requirements changed the decision
The real progress started only after I stopped jumping between tools and wrote down what I actually needed.
- I needed an admin layer for content.
- I needed a reusable structure for articles and pages.
- I needed a system I could evolve gradually.
- I needed control over layout, typography, and information architecture.
- I needed the site to work not as a structured professional document.
- I needed something predictable, maintainable, and economically sane.
Only after that did the right direction become obvious.
I ended up with WordPress and code. That may sound like a step backward if you think only in categories like modern versus outdated. In practice, it was the first realistic decision that fully matched the product.
No-code platforms often promise freedom but deliver rented flexibility. You can move blocks, change appearance, and assemble pages, but only within someone else’s model, someone else’s pricing logic, someone else’s limitations, and someone else’s roadmap.
WordPress with a lean setup and controlled code gave me something more valuable than novelty: control over structure.
I was no longer trying to outsmart a platform. I was finally building a system.
What the site became
Once the stack was chosen, I could define the final result properly.
- The site is not a classic portfolio.
- It is not a service landing page.
- It is not a visual showcase.
- It is a document-passport of a specialist.
Its purpose is to define, in a clear and structured way, who I am, what I do, how I think, what kind of tasks I solve, and how I adapt to new contexts and constraints. It demonstrates not only output, but reasoning, structure, and maturity.
- The form is part of the argument.
- That is why the site uses a document-like style.
- That is why the navigation is structured.
- That is why the language is dense and explicit.
- That is why there is no marketing layer pretending to be meaning.
If I claim that I work with complexity, systems, requirements, and product logic, then the site itself has to prove that claim through its architecture.
- Cases show what I did.
- Articles show how I think.
- The structure itself shows how I formalize chaos.
In that sense, the site is not only a place where I present work. It is itself a finished piece of work.
Implementation: from abstraction to production
Once I committed to this path, I installed WordPress locally through Local and started assembling the site in a real environment.
At one point I also tried a builder plugin to speed up the process. That experiment ended quickly. The promise was convenience, but the result was duplication, hidden controls, scattered logic, and unnecessary complexity layered on top of native functionality.
That experience reinforced another conclusion:
Tools that claim to remove complexity just hide it. A harder path is better when complexity is visible, honest, and manageable.
After that, I switched to a cleaner setup. I chose Twenty Twenty-Four as the base theme because it was closer to the structure I needed.
I did not design the whole thing in Figma first and then translate static screens into a real site. That would have created a false intermediate step. Figma is useful for many things, but for this project it would have produced a static artifact that could not validate the real behavior of content, structure, and responsiveness in an actual environment.
So instead of building a mockup first, I defined a compact design system directly around the real product. Typography, spacing, layout logic, content blocks, and structural patterns were all shaped in context. Part of that was done natively inside WordPress. Part of it required code adjustments in the theme files, where Claude helped as a second pair of hands.
AI operated inside a system I had already defined. A defined product gives AI a surface to work on. Without a defined product, AI produces faster uncertainty, not a faster result.
The outcome
I started by looking for no-code because I wanted to avoid unnecessary technical work. I ended with WordPress and code because that was the only configuration that matched the defined product.
The stack was not the achievement. The definition was. Once the definition existed, the stack selected itself.
A tool does not define a product. A defined product selects its tool.
n