Logo
  • Home
  • Topics
    • Architecture
    • Engineering
    • Life
  • English
    • English
    • PortuguêsPortuguese
    • FrançaisFrench
    • ItalianoItalian
    • EspañolSpanish
    • 日本語Japanese

© Samuel Britto. All rights reserved.

Architecture

Architecture over Ego: Why I Stopped Building My Own Backend After 11 Years

For most of eleven years, my reflex when something needed a backend was to write one. Not because it was the right call every time, but because building is the part I enjoy and I was good enough at it to get away with the habit. For a long stretch that habit was a tax I paid to my own ego, and I told myself it was craftsmanship. Early in 2025 I finally stopped paying it, for one project at least.

1. The Legacy: High Standards, Fragile Backend

My portfolio has always been something I'm proud of, but its foundation had become a time capsule. For years a small PHP backend parsed data out of INI files; later the frontend just read raw JSON straight off disk. The presentation was polished and the workflow was miserable. Every typo, every project update meant opening an editor, changing a file, pushing a commit. I remember wanting to fix a single sentence from my phone, away from my desk, and realizing I couldn't do it without a full deployment. That was the moment the habit stopped feeling like craftsmanship and started feeling like a cage I had built myself.

2. Rediscovering "Headless"

I didn't want to hand-build an admin interface from nothing — even I could hear the ego in that — so I went looking at what already existed. The search led me back to the headless CMS: the frontend fully separated from the content store, data served anywhere over an API. I had worked with this shape before at an enterprise scale, but I had not kept up with how far the independent tools had come.

The SaaS giants — Contentful and its neighbors — are genuinely capable, and they also charge by the record, with API ceilings that read like a countdown timer for anything that grows. I did not want a subscription invoice that punished me for using my own site. I wanted to own the code and the database outright.

3. Evaluating the Self-Hosted Landscape

So I looked only at things I could host myself, and audited the ones people actually use:

  • Ghost — excellent at publishing, too rigid for a portfolio that is not just a stream of posts.
  • Directus — a serious tool for mirroring a database, but the interface is built for engineers, not for sitting down to write.
  • Payload — a sharp code-first approach that I liked, except it wanted me to define every field in code before it would show me a dashboard.
blog/architecture-over-ego-strapi-migration.svg

4. Why Strapi, For Now

Strapi sat in the space between a finished application and a framework. The interface is good enough that I can make a change from my phone, and it never locks the door on the code — it runs on Node, so a lifecycle hook or a custom controller is there when a standard CMS would leave me stuck. It treated six locales as first-class objects instead of an afterthought, let me shape schemas without hand-writing them, and turned a post into something modular: blocks I could stack rather than one slab of markup.

When I started this blog a few months later, I did not begin again. I extended the models I already had and pointed a second frontend at them. The static file-reader had become an engine serving two projects.

Conclusion

None of this was a conversion story. I still reach for a from-scratch build more often than I should, and I still think that instinct is worth having. But it belongs on the projects where being wrong only costs me — not on the one piece of infrastructure that needs to be boring and dependable. Choosing the tool here was the harder call, and for once I made it.

The foundation is laid; now it's time to build.

  • Strapi
  • Self-Hosting
  • TypeScript

Share

  • Facebook
  • X
  • LinkedIn
  • WhatsApp
  • Reddit
  • Telegram
  • Email
  • 0 responses