I finally launched Lubinik.dev.

That sentence sounds much cleaner than the actual story behind it.

Lubinik did not begin as a polished framework with a name, a roadmap, and a public website waiting at the end. It started much more quietly: with WordPress projects that kept asking for the same foundations, the same structure, the same admin tools, and the same kind of separation between what belongs to one site and what should be reusable.

At some point, the thing I was building for client work became a system of its own. Lubinik.dev is the place where I can finally document that system properly.

And because every framework apparently needs a name with a tiny private mythology behind it: Lubinik came from my search for something unique, mixed with the names of my two dogs, Blu and Niki. It sounded unusual enough to belong to the project, so it stayed.

Not a product launch, exactly

I do not think of Lubinik as a product I am trying to sell.

It is more personal than that. It is my WordPress framework, my working memory, and the architecture I use to stop rebuilding the same foundations by hand every time a new project begins.

The public site is not meant to pretend that the framework appeared fully formed. It is built as a journal because that is the honest shape of the project. Lubinik grew through real websites, refactors, messy first versions, annoying repetitions, and small decisions that only became obvious after the wrong version had already taught me something.

So the launch of Lubinik.dev is less “here is a finished thing” and more “here is the story of how this thing became useful enough to deserve its own home.”

What Lubinik is

Lubinik is a custom WordPress framework made of several layers that each have a specific job.

• The parent theme handles the shared site mechanics: layout structure, menus, headers, footers, reusable sections, templates, and theme-side tools.
• The core plugin provides the shared backend layer for addons: admin systems, shortcode registration, template loading, reusable components, assets, galleries, calendars, filters, tabs, and utility shortcodes.
• Addons carry the domain logic for specific kinds of sites, such as BnB websites, animal shelters, comics, resumes, freelance portfolios, and showcase content.
• Child themes hold the visual identity, project-specific templates, design packs, and site-level configuration.
• Support plugins handle things like translation, SEO, structured data, API output, updates, and other systems that need to connect cleanly without becoming part of every project by default.
• The scaffolder turns repeated addon and child-theme structure into configuration, so starting a new project does not depend on fragile copy-paste.

The point is not to make everything abstract. The point is to keep the right things in the right places.

Why it needed its own site

For a long time, Lubinik existed mostly inside repositories, local WordPress installs, private notes, and the sites built with it.

That worked while the system was small. But once the framework started to include a parent theme, a core plugin, several addons, child themes, support plugins, a private updater, local sync tools, and a scaffolder, it became harder to explain the project from the outside.

The website gives the framework a readable shape. It can show the components, document the case studies, and keep the chronological blog posts together so the evolution of the system does not disappear inside commit history.

That matters because Lubinik is not only code. It is also a record of decisions.

The journal matters

The blog on Lubinik.dev is intentionally written as a journal.

It starts with the first frustration: trying to make peace with WordPress, building a BnB theme, and realising that some parts of the work were being rebuilt too often. Then it follows the project through the first refactors, the separation between theme and plugin, the BnB addon, the shelter addon, dynamic templates, child themes, design packs, support plugins, AI-assisted development, the scaffolder, private updates, and the moment the system became maintainable enough to trust across real sites.

I wanted that history to stay visible because it is the most honest way to explain the framework. Lubinik did not come from theory first. It came from building real things and listening when the same problems returned in different costumes.

A framework is not only a set of reusable files. It is also the memory of what became painful enough to deserve a better system.

Built with the system it documents

There is a small satisfaction in the fact that Lubinik.dev is also a Lubinik site.

The site is not just a brochure about the framework. It uses the framework’s own logic: a child theme for the visual layer, showcase content to present components and tools, blog posts to document the journal, and the same architectural discipline that Lubinik is meant to bring to other projects.

That makes the site a kind of proof. Not a perfect one, because no personal framework is ever really finished, but a living one. If the system is supposed to help me build and maintain custom WordPress sites, then its own website should be able to stand on that foundation too.

What launching it changes

Launching Lubinik.dev does not mean the framework is complete.

It means the project is now visible enough to be documented in public. It means the architecture has a place to be explained. It means future changes can be added to a timeline instead of disappearing into private notes. It also means I can point to the system behind my client work without turning every explanation into a small oral history of my WordPress decisions.

And, honestly, it gives the project a little more accountability. Once something has a public home, it becomes harder to treat it like a pile of folders that only I vaguely understand.

Looking forward

The next phase of Lubinik is not about making it bigger for the sake of it.

It is about making the existing pieces calmer, clearer, and easier to reuse: better scaffolding, cleaner child-theme generation, more reliable updates, stronger API surfaces, better SEO and structured-data support, and practical addons that continue to grow from real projects instead of abstract feature lists.

Lubinik.dev gives that work a place to live.

Not as a final announcement, but as an ongoing journal of a framework that started accidentally and slowly became one of the most useful things I have built.