For a while, my relationship with WordPress was mostly avoidance with a side of resignation.
I did not like Gutenberg. I did not like the feeling of fighting the editor to build something that, in my head, should have been more direct. Oxygen helped for a while because it created distance between me and the parts of WordPress I did not enjoy. It gave me a builder, a visual layer, a way to get sites done without constantly wrestling with the default experience.
But that kind of peace had a ceiling. At some point, I realized I did not only want to finish WordPress sites. I wanted to understand them. I wanted to know how the templates worked, where the data lived, how the admin could be shaped, how custom post types could become real editorial tools, and how far I could go without handing the whole structure to a visual builder.
Code-first, but not hostile to the admin
The answer was not to reject the WordPress admin completely. I still wanted admin screens, fields, settings, sortable sections, galleries, taxonomies, and normal content editing. I just did not want every layout decision to be trapped inside a visual interface.
That became one of the quiet principles behind Lubinik: the admin should help manage content and choices, but the architecture should stay readable in code.
This is why Lubinik never tried to become a page builder. It became something else: a code-owned system with admin-managed switches. Templates stay in files. Sections are shortcodes. The manager decides which sections are active, in which order, and with which basic settings.
It is a compromise, but it is a compromise that fits how I work. I can still build carefully. I can still reuse things. I can still give myself admin control where it helps. And I can keep the structure visible enough that future me, or an AI assistant, can understand what is going on.
