Recodecommerce.com used to run on a custom CMS that worked well enough on the technical side. The problem was usability. Adding a new page, changing homepage content, or expanding the site structure was slower than it should have been.

The site needed more than a few static pages. It needed a flexible homepage, service pages, plugin pages, a contact page, blog posts, SEO controls, and hidden pages that could be shared only through private links. The old setup could support parts of that, but not in a way that felt practical for daily use.

Instead of moving to a larger CMS, we decided to build a smaller one around the actual requirements. That decision became NestCMS.

The starting point

The first goal was simple: make content management easier. We wanted to manage core business pages from the admin area, publish blog content without workarounds, and keep control over SEO settings on each page.

We also needed restricted pages for selected audiences. Some content should be public. Some content should only be accessible through token-based links.

What we built

NestCMS evolved into a lightweight PHP CMS with hierarchical content, blog categories, audience-based access, theme separation, and a practical admin area. The structure became more flexible over time, especially after moving away from a rigid two-level page model.

That change mattered. Real websites do not stay flat for long. Once service pages, nested content, and blog structures start growing, the CMS has to reflect that naturally.

What we learned

The biggest lesson was that content structure is not a minor detail. If the model is too rigid early on, every later improvement becomes more expensive. Reworking routing and hierarchy was one of the most important steps in making the system usable for real projects.

Another lesson was the value of separating admin and frontend themes. A CMS becomes easier to maintain when the internal workflow and the public website can evolve independently.

Why this case matters

NestCMS was not created as a theoretical product. It came from a real content management problem on a real business website. That is why the project stays focused on practical use instead of unnecessary feature inflation.