Thanks a lot for the honest feedback. I really appreciate this kind of answer because it helps me understand what is not clear from the outside.
The original problem behind Tagixo comes from my own client work.
Many times I found myself building both a website and a custom management system for the same client. For speed, I often used WordPress with Divi for the website, while the actual business logic, workflows, data models, permissions and internal tools were built with Laravel.
The problem usually appeared when the website needed to display or interact with data from the Laravel backend. At that point, the frontend could no longer be managed visually and I had to build everything by hand. That is obviously fine in many cases, but it also meant duplicating effort and spending much more time on parts that, in my opinion, could have been managed in a more flexible way.
So the original idea behind Tagixo was not to replace Laravel, Filament, or custom development. It was to make a Laravel application capable of behaving more like a CMS when needed, with a visual builder integrated directly into the Laravel ecosystem.
The main audience is still developers. I am not trying to build a “no-code platform” where the developer disappears. My goal is to give Laravel developers a tool that can be used as a starting point, or as a flexible layer for the parts of an application that need to be editable, configurable, or reusable.
For example, Filament is great for building the admin panel and internal tools. Tagixo is more focused on the frontend side: pages, sections, content, forms, emails, PDFs and other parts that often need to be customized or maintained over time. There is also an official Filament plugin that makes Tagixo ready to use inside a Filament project. Forms can also be used inside Filament when a more dynamic form-building experience is needed.
So I see Tagixo less as “build your whole app visually” and more as “give your Laravel app a visual CMS-like layer where it makes sense”.
About trust, vendor lock-in and closed source: I completely understand the concern. As a developer, I would have the same doubts before adding a dependency like this to a real project.
The first thing I can say is that I am the first user of Tagixo. I built it because I needed it in my own work, and I intend to keep using it myself. If one day I were no longer able to maintain it, my intention would be to open-source it out of respect for the people who trusted the project.
Regarding breaking changes, I tried to design the system in a way that avoids real breaking changes as much as possible. Most classes are extendable, and many parts of the system are configurable. If a breaking change ever becomes necessary, I would provide a clear migration path and, where possible, migration scripts to help users move forward safely.
That said, I agree that I need to make this clearer in the documentation. Trust cannot be based only on what I say in a forum post. It needs to come from documentation, examples, stability, transparency, and real use cases.
About the server crash: you are right to point that out. It was bad timing and it was my fault. I was deploying some hotfixes for a mobile viewport issue on the website, and unfortunately some bugs only appeared in production. I had to restart the server while working on it.
That is not the kind of experience I want people to have when discovering the product, especially for a tool that should inspire confidence. I take that seriously.
Your point about Tagixo looking like a collection of features is probably the most important one for me. I think the product makes sense, but I clearly need to communicate the original problem better.
The problem is not “Laravel needs a visual builder for everything”.
The problem is that many Laravel applications eventually need editable pages, dynamic forms, reusable content, emails, PDFs, or client-managed frontend sections — and developers often have to rebuild those pieces from scratch every time.
That is the space where I am trying to position Tagixo.
Thanks again for the detailed feedback. It gives me a lot to improve, especially around positioning, documentation, trust, and explaining the actual use cases more clearly.
