In 2022, I hit a wall. We were shipping yet another client project. Deadlines were tight. And once again, I was staring at the same problem I’d solved a dozen times before: building an admin panel from scratch. I opened my terminal. I sighed. Then I opened our old Tabler-based template folder, renamed a few files, and got to work wiring up yet another CRUD UI. It was fine. It worked. But I kept thinking: Why am I doing this again? Why am I doing this again? Why am I doing this again? That’s when it clicked. I wasn’t just frustrated — I was wasting time. Rebuilding the same logic, over and over. Tables, forms, filters, buttons. A little jQuery here, a hacked-together permissions check there. Slightly different every time, but fundamentally the same. So, I decided to build the admin panel I actually wanted to use. This is the story of how Admiral was born. This is the story of how Admiral was born. Admiral We don’t use Wordpress or ready-made CMSs: everything we build is custom. So, for every client project, we end up needing a new admin panel tailored to that business. 90% of the time, it’s standard CRUD logic—products, users, categories, orders, whatever. The other 10% involves weird dashboards, complex data relationships, or one-off tools that the business needs behind the scenes. Every time, the same question comes up: How do we move faster without sacrificing flexibility? I knew what kind of tool I was dreaming about. It had to tick all the boxes: [ ]Be able to scaffold standard CRUD views quickly [ ]Let us create custom pages just as easily [ ]Look clean and modern by default [ ]Be easy to style per project [ ]Work with any backend (not just Laravel or Node) [ ]Rely on REST APIs [ ]Be built on React [ ]Be able to scaffold standard CRUD views quickly [ ] [ ]Let us create custom pages just as easily [ ] [ ]Look clean and modern by default [ ] [ ]Be easy to style per project [ ] [ ]Work with any backend (not just Laravel or Node) [ ] [ ]Rely on REST APIs [ ] [ ]Be built on React [ ] So, I started looking for tools that could do all that (and maybe more?). What we tried (and why it didn’t work): We tried a bunch of existing solutions. We also tried building our own (not once, but three glorious times). Each time, we got stuck on architecture decisions and abandoned the effort halfway. The first attempt at making it reusable The first attempt at making it reusable We used Tabler to start—first with Blade templates, then with some React components. Tabler Tabler When we discovered Laravel Nova, we liked its structure and started building our own version of it using React and Ant Design. Here’s what defining a resource looked like at that point: It worked. CRUDs were faster to create. The UI felt clean. But… the whole thing was tightly coupled to Laravel. It worked Which brings us to the next big decision. The more we used this system, the more friction we hit: You had to run the full backend just to work on the frontend. Frontend devs were blocked on backend logic. JSON responses were tightly structured and hard to modify. Custom pages were hard and often required both frontend and backend collaboration. You had to run the full backend just to work on the frontend. Frontend devs were blocked on backend logic. You had to run the full backend just to work on the frontend. Frontend devs were blocked on backend logic. JSON responses were tightly structured and hard to modify. JSON responses were tightly structured and hard to modify. Custom pages were hard and often required both frontend and backend collaboration. Custom pages were hard and often required both frontend and backend collaboration. hard So, I made the call: Let’s split the admin panel into a fully standalone React app! Let’s split the admin panel into a fully standalone React app! Now, it works like this: Now, it works like this: Frontend is an SPA that talks to REST APIs. Backend can be anything—PHP, Go, whatever. CRUDs are configured by backend devs. Custom pages are handled by frontend devs, using mock data or real endpoints. We use code generators to handle repetitive stuff. Frontend is an SPA that talks to REST APIs. Backend can be anything—PHP, Go, whatever. CRUDs are configured by backend devs. Custom pages are handled by frontend devs, using mock data or real endpoints. We use code generators to handle repetitive stuff. This is what became Admiral. This is what became Admiral. Admiral We started building it in April 2022, while working on a commercial project that needed it. By June 2023, we had a working version. Total time? Around 700 hours. Total time? Around 700 hours. Since then, we’ve rolled it out to 10+ client projects, and it’s running great. Today, almost all of our front-end devs contribute to it. The goal was to make Admiral our standard admin UI framework for internal use, maybe public someday, and that day is now. and that day is now At the very least, it’s saving us time. It’s making our projects cleaner. And most importantly: it lets my team work the way we actually want to work. Next up: I’ll show how Admiral works in practice—how we define resources, structure custom pages, and why our devs actually like working with it. Next up: like Stay tuned!
