Why we built a custom CMS instead of using WordPress (and when you should too)

How and why?

When Ema and Matija from Putujem s TravEM came to us with their travel blog idea, the brief wasn't really about a blog at all. They wanted something that felt like travel. Not a list of posts with a sidebar and a search bar: something with energy, personality, and a visual language that matched the way they actually experience the places they visit. That brief ruled out WordPress before we even opened a text editor.

The starting point

At the beginning of our travel platform project, we faced a familiar decision: Should we go with a proven solution like WordPress, or build a fully custom CMS from scratch?

WordPress is often the default, and for good reason. It's fast to launch, widely supported, and flexible enough for many use cases.

But our goal wasn't to build just another blog. We wanted to build the best travel blog in Southeastern Europe.

---

"They all look the same"

Most travel blogs look the same. Header image, post title, wall of text with affiliate links, related posts at the bottom. Functional. Forgettable.

Ema and Matija didn't want a travel blog in that sense. They wanted a destination - a place that felt as considered as the trips they were writing about.

The requirements started stacking up quickly:

• A homepage that felt editorial and alive, not a paginated post feed
• Custom destination cards that used actual map imagery alongside photography
• Content layouts that could flex depending on what the article needed - not a single rigid template
• A browsing experience that invited exploration rather than just reading
• Consistent visual identity, from typography choices down to how individual photos were presented
• Interactive maps and UI elements
• Structured, SEO-driven content with large reach
• Overall, attractive UI design that no one in the Southeastern Europe has

None of these are things you assemble from plugins without significant trade-offs. They're design decisions that need to be built into the foundation.

That's where the difference becomes clear.

The WordPress conversation

We always have this conversation with clients. WordPress is genuinely good software with a massive ecosystem. For many projects, including complex, high-traffic ones, it's the right answer.

But we walked through what building this in WordPress would actually look like. The homepage would require a heavily customized theme or a page builder like Elementor or Bricks. Every unique section - the animated hero, the map-based destination cards, the editorial article grid - would mean either a custom block, a third-party widget, or a workaround. And those workarounds would need to survive every future core update.

The article layouts would need ACF (Advanced Custom Fields) or a similar plugin to handle flexible content. Which works, until you need logic that ACF wasn't designed for, and suddenly you're writing PHP to patch gaps between plugins. Performance would take hits under this specific visual scope. Page builders add markup; plugins add scripts. A visually rich travel site with large imagery is already heavy, and you don't want the CMS adding to that weight before a single photo loads.

The maintenance story wasn't great either. A stack of plugins, each on their own update schedule, each potentially conflicting with the others, each requiring attention when something breaks.

At some point in that conversation, the answer became obvious.

Note: WordPress is a powerful platform that scales to large, high-traffic websites. The trade-offs above are specific to the heavily customised, visually unique use case described here — not a general indictment of WordPress.

What we built instead

We built Putujem s TravEM as a fully custom Next.js application, with a custom CMS backend in Express.js built specifically for how Ema and Matija actually work.

The frontend is exactly what the brief described: a site that looks and feels like a travel magazine rather than a blog template. Each destination has its own visual treatment. The homepage is editorial. The article layouts are flexible because they were designed to be, not because a plugin made them technically possible.

The CMS is a custom admin panel built around their content workflow. Performance was good by default, not something we had to fight for. No plugin overhead. No unused scripts. Just Next.js rendering what the page needs, when it needs it.

Scalability was designed in from the start. As the site grows: more destinations, more content types, more features, the architecture accommodates that growth without structural surgery.

What This Looks Like in Practice

The difference between "built for everyone" and "built for this" isn't abstract. It shows up in specific moments.

When they wanted a newsletter system, we built it directly into the CMS. New article published? Subscribers get notified automatically. Manual send when needed? One button. No third-party plugin to configure, no extra subscription to manage.

When they wanted to change how destination cards looked and behaved across the whole site, it was a single component change. Not a theme option buried in a settings panel, not a CSS override fighting a page builder's inline styles — just the component, updated once, reflected everywhere.

GA4, Google Search Console, and Google Ads were all connected directly, with no additional plugins and no added cost per integration. In a WordPress plugin-heavy setup, each of those would typically mean another plugin, another settings panel, and another potential point of failure.

Budget Travelers, Budget-Conscious Build

There's a certain irony in building a budget travel blog on expensive infrastructure. Ema and Matija write about finding flights for 35€ and fitting a week's worth of clothes into a Ryanair backpack. Their audience watches every euro. So do they.

This made the cost conversation interesting.

On the surface, WordPress looks cheaper. You can get a theme for €60, a few plugins for €100/year each, and be live in a week. But we mapped out what the real 3-year cost would look like for a site with their visual requirements: a premium page builder license, ACF Pro, a forms plugin, a caching plugin, managed WordPress hosting with enough headroom for image-heavy pages, and a developer on call whenever a plugin update broke something.

It adds up faster than people expect.

Important caveat: The custom build has a higher upfront investment. Ongoing maintenance costs, while lower in plugin licensing, can be higher per hour when specialist work is needed — since custom codebases require developers familiar with the specific stack. The cost advantage depends heavily on how stable and well-documented the custom system is.

For a project where the design vision was non-negotiable and the long-term budget was tight, the math favored going custom. Not necessarily cheaper overall, but differently structured — with fewer recurring plugin costs and no plugin-conflict debugging.

---

Here's how the two approaches stacked up against what the site actually needed:

---

The Honest Version of the Tradeoff

Custom isn't always the answer. If Ema and Matija had wanted a standard travel blog, even a really well-designed one within familiar conventions, WordPress would have been faster and cheaper to start, and would have served them well.

But they didn't want that, and they were clear about it from the beginning.

The investment in a custom system pays off when:

• The design vision can't be approximated by a theme or a page builder
• The content model doesn't fit the standard post/page/category structure
• Performance isn't something you want to negotiate with your CMS layer
• The product is meant to grow in specific ways that need to be designed for

For Putujem s TravEM, all four were true.

The result is a site that looks and works exactly how it was imagined — not like a WordPress blog that got really creative with Elementor.

---

Putujem s TravEM is a Croatian travel blog by Ema and Matija. It was designed and developed by Fosleen. Read the full case study → How we built Putujem s TravEM