After 11 years in the industry, I’ve learned that the most expensive thing you can do is build something you could have bought—or in this case, configured. We often feel the urge to prove our technical depth by building everything from scratch, but for a long time, this was just a creative tax I paid for my own ego. The real challenge is knowing when to use a tool so you can focus on the art of the implementation.
My portfolio has always been a project I’m proud of, but until recently, its technical foundation felt like a time capsule. For years, I managed everything with a simple PHP backend that parsed data from INI files. Eventually, I transitioned to a setup where my frontend was reading raw data directly from local JSON files.
While the frontend was polished, the workflow was unsustainable. Every typo fix or project update required me to open my IDE, edit a file, and push a commit. I remember the frustration of wanting to update a single sentence while away from my desk and realizing I couldn't do it without a full deployment cycle. In early 2025, I decided it was time for a professional change. I wanted a robust, accessible backend that allowed me to manage content from a UI, on any device, without touching a line of code.
I didn't want to reinvent the wheel by building a custom administrative interface from scratch, so I started exploring the professional solutions already available on the market. That search led me straight to the concept of a "Headless CMS". For those unfamiliar, this architecture means the "head" (the frontend) is completely separated from the content repository, allowing data to be served anywhere via API. I had actually worked with this architecture before at an enterprise level, but I wasn't familiarized with how much the independent market had evolved.
I quickly discovered a massive range of options, starting with the "industry giants" in the SaaS (Software as a Service) space, like Contentful. These platforms are powerful, but they often come with restrictive "pay-per-record" tiers and API limits that feel like a ticking time bomb for a growing project. As an engineer, I didn't want my growth to be penalized by a subscription invoice. I wanted Data Sovereignty—I wanted to own the code and the database.
I pivoted exclusively to self-hosted options, searching for a tool that balanced technical "purity" with administrative ease. I audited the current leaders:
Strapi stood out because it represents the perfect middle ground between a "ready-to-go" application and a highly customizable framework. It provides a polished, intuitive UI that is a lifesaver when I need to make quick updates from my phone, but it never traps me in a "low-code" bubble. Because it is built on Node.js, I still have the power to write custom lifecycle hooks or extend API controllers whenever I need logic that a standard CMS can't provide.
This balance allowed me to scale my infrastructure without the friction I faced in the past. The ecosystem is packed with features that made it the clear winner:
When I launched this blog, I didn't have to start over. I simply extended my existing Strapi models to serve both projects. It transformed my backend from a static file-reader into a scalable, multi-project engine.
I created this blog to inspire other developers to value engineering efficiency. It’s easy to get lost in the "coolness" of building from scratch. It’s much harder—and more rewarding—to choose a foundation that balances deep technical control with a human-centered interface.
The foundation is laid. Strapi handles the rest. Now, it's time to build.
