DEVKEV started as a personal site for documenting what I was learning about AI, agents and automation, but the build quickly became an experiment in its own right.
Rather than use Elementor in the way I had before, I decided to build the site around its newer Atomic system, with reusable classes, design variables, ACF fields and dynamic content. The aim was to create something that felt more structured and maintainable than a traditional page-by-page Elementor build.
That choice added a learning curve, but it also forced me to think more carefully about how the site should work as a system. Shared classes, dynamic loops, semantic headings and structured content all became part of the build rather than something added later.
AI also became part of the process, not as a replacement for the build itself, but as a way to troubleshoot, structure ideas, test approaches and gradually automate parts of the site around it.
Why I chose Elementor Atomic
I had used Elementor before, so I was familiar with the general way it worked. Atomic felt different almost immediately.
Instead of treating every element as its own isolated piece of styling, Atomic pushes you towards reusable classes, shared variables and a more systematic approach to layout. That appealed to me because DEVKEV was never meant to be a one-page experiment. I wanted something I could keep adding to without the design gradually drifting apart.
The trade-off was that small changes could have much wider consequences. A class used in one section might also be controlling several others, and leaving a spacing value blank could create behaviour I had not intended. I had to stop thinking in terms of “fix this element” and start thinking more in terms of “what system is this element part of?”
That took some adjustment, but it also started to make the site feel much more coherent.
Building the content structure
One of the first things I needed to work out was what DEVKEV was actually going to publish.
I did not want the site to become a generic stream of AI news, so I split the content into three distinct areas.
Signal is for developments that are worth paying attention to. These are usually external stories, tools or announcements, but the aim is to add some context around why they matter rather than simply repeat the headline.
Lab is different. That is where I document things I have actually built, tested or learned from myself. The DEVKEV site itself belongs in that category because the build has involved real decisions, mistakes and changes rather than being a theoretical exercise.
Currently Testing sits somewhere between the two. It is deliberately lighter and only appears on the homepage. It is there to show what I am actively working on without turning every experiment into a full article before I have anything useful to say about it.
That structure gave the site a clearer purpose. Signal shows what I am watching, Lab shows what I have actually done, and Currently Testing shows what is still in progress.
Using ACF and dynamic content
Once the content structure was clear, ACF became the piece that made it practical.
Rather than treating every post as one large block of text, I used custom fields for the parts that needed to appear consistently across the site. Signal posts have fields such as Why It Matters, while Lab posts use structured fields for What I Tested, What Happened and Verdict.
That made the Elementor templates much more useful. The homepage cards, archive pages and single-post layouts can all pull the same structured information dynamically, so I do not have to rebuild each post by hand.
It also made the automation work possible later. Because fields such as why_it_matters already had a defined place in WordPress, n8n could publish into the same structure rather than dumping everything into the main post body and hoping the template could make sense of it.
The biggest benefit has been consistency. Once the template is built properly, the content can change without the layout changing with it.
The mistakes that taught me the most
The most useful lessons came from the parts of the build that went wrong.
Atomic classes are powerful because one class can control multiple elements across the site. That is also where the danger is. Early on, I changed a shared class while working on one section and unintentionally affected several others. It was a good reminder that a reusable class is effectively site-wide infrastructure, not just a local styling shortcut.
Spacing caused similar problems. In Atomic, leaving a value blank does not always mean “nothing”. It can inherit another value or fall back to something I was not expecting. I learned to explicitly set values such as margin and padding to 0 when no spacing is intended rather than leaving them empty.
Responsive behaviour also needed a different mindset. A desktop change can cascade down to tablet and mobile unless a breakpoint has its own override, so I had to get into the habit of checking the inheritance rather than assuming each device view was isolated.
The other lesson was semantic structure. I initially treated headings mainly as visual elements, but it became clear that the HTML hierarchy and the visual styling needed to be considered separately. A decorative label does not need to be an H2 just because it looks like one, and a page should still have a sensible heading structure underneath the design.
None of these were dramatic failures, but together they changed how I approached the rest of the site. The more I treated Atomic as a system rather than a page builder, the more predictable the build became.
Where AI actually helped
AI was involved throughout the build, but not in the sense of asking it to “make me a website” and accepting whatever came back.
The useful part was having something to reason through decisions with. I used AI to troubleshoot Elementor behaviour, think through class structure, test naming conventions, work out why responsive inheritance was behaving unexpectedly and sanity-check how the templates were put together.
It was also useful when the problem crossed into areas I knew less well. REST authentication, WordPress API behaviour, n8n workflow design and ACF integration all became much easier to work through when I could test an idea, inspect the result and adjust the approach quickly.
That does not remove the need to understand what is changing. In fact, the build reinforced the opposite. Shared classes, automation and API access can all affect more than one part of the system, so blindly applying suggestions would have created more problems than it solved.
The value was in using AI as part of the problem-solving loop: try something, inspect what happened, understand why, then make the next change deliberately.
Turning DEVKEV into a live system
Once the site structure was working, the next step was to make DEVKEV do more than simply sit there waiting for me to update it manually.
That is where n8n, Discord and Rez, the AI operations assistant I use through Hermes, started to become part of the project.
The Signal workflow now checks The Rundown AI feed every six hours and looks for stories that have not already been shown to me. It sends the newest unseen items to Discord as a short numbered digest, capped at 10 stories so it stays useful rather than becoming another noisy feed.
From there, I stay in control. I choose the story, Rez asks what interests me about it, researches the source, traces back to the original material where possible and then writes a complete DEVKEV Signal article for review.
Nothing publishes at that point.
The article is shown to me in full first, including the title, excerpt, main content, Why It Matters and source information. I can ask for changes or reject it completely. Only when I explicitly reply Publish or Go does n8n create the WordPress post.
The workflow then writes the post content, assigns the Signal category, fills the ACF field, applies the default featured image, publishes it and reads the result back through the WordPress REST API to make sure the article that went live is actually the one I approved.
That part matters to me. The automation saves time, but it does not remove the editorial decision from the process.
What I’d do differently
If I started DEVKEV again tomorrow, I would make a few decisions earlier.
The first would be to define the content structure before doing as much visual work. Once Signal, Lab and Currently Testing had clear roles, the rest of the site became easier to organise because I knew what each template actually needed to support.
I would also be stricter with Atomic classes from the beginning. Shared classes are one of the strongest parts of the system, but only if they are treated deliberately. Naming, inheritance and where a class is reused all matter more than they initially appear to.
The same applies to spacing. Explicit values are safer than assuming a blank field means nothing, particularly when styles are inherited across breakpoints.
I would separate semantic structure from visual styling earlier too. Getting the heading hierarchy right first and then applying the visual treatment through classes makes the site easier to maintain and avoids having to correct markup later.
And on the automation side, I would resist the temptation to build too much intelligence into the workflow too early. The first version became more complicated than it needed to be. Keeping the human approval step and letting automation handle the repetitive parts has proved to be the better balance.
Most of those lessons came from small mistakes rather than major failures, but they have made the second half of the build much cleaner than the first.
Verdict
Elementor Atomic has taken more effort to learn than a conventional Elementor build, but I think that effort has been worthwhile.
DEVKEV now feels less like a collection of individually designed pages and more like a system. The classes, ACF fields, templates and automation all have defined roles, which should make the site easier to expand without gradually losing consistency.
The biggest change for me has been in how I think about the build. Instead of asking how to style one element or automate one task, I am increasingly thinking about how each part fits into the wider structure.
There is still plenty I want to test, but that is really the point of DEVKEV. The site is not just where I document the experiments. It has become one of them.