Two similar projects. One succeeded. The other we walked away from — and no, it wasn't a budget problem, it wasn't the technology, and the team didn't drop the ball.

Both companies operated in similar industries. Both were large, production-scale businesses with presence across multiple markets. Both had extensive product ranges and a very similar problem: their product catalog had stopped keeping pace with the scale of the business.

The start looked promising for both. A solid brief. Meaningful conversations. Ambitious goals.

And yet the outcomes couldn't have been more different.

The fate of a product catalog project is rarely determined by design or technology. Far more often, it comes down to how the organisation makes decisions.

The brief had taken a long time to put together. It was detailed, multi-threaded, touching on everything from brand positioning to technical infrastructure. It brought together the interests of many departments and was the result of serious internal work.

The operational goals were reasonably clear: better product presentation, streamlined catalog management, PIM integrations, preparing the catalog for internationalisation, and a range of improvements to support employees in their day-to-day work. The business KPIs were fairly broad, but at that stage they didn't raise any red flags.

In both cases, we were invited to review the brief.

We discussed the assumptions, asked questions, and proposed adjustments. The early conversations looked very similar: grounded, substantive, with clear strategic threads and a coherent vision of success.

The decision was made: we take on both projects.

Workshops began, and detailed needs analyses got underway. At that point, both projects looked almost identical — equally complex, equally interesting, and a good fit for our capabilities.

Interestingly, the two projects were carried out with a considerable gap between them. That meant they were handled by almost the same team on our side — the same roles, very similar experience and skill sets. The personnel differences were minimal.

From that angle, it's hard to argue that the design team was the deciding factor.

And yet the outcomes turned out to be completely different.

In the first case, the catalog was delivered on time — which, for a project with this level of estimation risk, is by no means a given — and today it is one of the company's most important sales infrastructure assets.

The second project we walked away from. It ultimately dragged on for over five years, went through multiple vendors, saw staff come and go, and descended into chaos.

The turning point in the failed project came after the first round of workshops. As we began digging into the details with people across the organisation, it became clear that the company needed something quite different from what it had described in its brief — and what it had been saying in the early meetings.

It quickly emerged that the document had taken almost two years to produce. The person who had written it had since left the company, and nobody in the organisation felt responsible for checking whether it was still relevant.

The company had simply assumed that because the brief existed, it must be correct.

The workshops rapidly turned into a battle over project scope. New opinions kept surfacing, new ideas emerged, further revisions were requested. An outdated brief had triggered a phenomenon well known in large organisations: decision paralysis.

There was no single source of truth, and any attempt to create one required involving far too many people.

In contrast, in the successful project, the brief wasn't rewritten — it was deepened. The organisation held to one direction, refining the details but never abandoning the core assumptions.

Everyone knew what framework they were working within.

Where the project sat in the organisation

The second significant difference was how each project was positioned within the organisation.

In the first company, the project was connected to board level — while at the same time, people from various levels of the organisation were actively involved.

In the second, the project sat solely at the level of the marketing director, supported by a project manager. Access to the board was closed off, and contact with representatives from other departments was severely limited.

In practice, this meant that in the first case we could analyse both strategic and operational goals, building a solution that served the interests of the whole organisation.

In the second, one person was the sole source of truth.

But the most decisive factor turned out to be someone else entirely.

In the successful project, a clear owner emerged very early on — someone who took responsibility for the whole thing. Not a board member. An operational leader: someone who understood both the business realities and how the organisation worked day to day.

This person was the one who connected the knowledge from different departments, kept the work aligned with the brief, and either made decisions themselves or secured them from the right people in the organisation when disagreements arose.

And there were plenty of disagreements. Product catalog projects inevitably raise questions that organisations tend to avoid:

In the first company, they led to decisions — helped along by a decision-making committee made up of representatives from various levels of the organisation.

In the second company, there was no real project owner. The project had been assigned to a single director-level role removed from the board, and no one operationally felt responsible for the whole.

As a result, for weeks on end the organisation couldn't make even basic decisions — completely destabilising the schedule. And the pressure kept building.

A product catalog isn't a technology project

In many companies, a product catalog is treated as an IT or marketing project.

A new CMS. A new design. A new category structure.

From that angle, the problem looks simple enough: gather requirements, design the interface, choose the technology. But reality is considerably more complex.

A product catalog is a cross-functional project. It touches sales, marketing, product development, operations, IT, customer service, and product data all at once.

Each of those areas has its own needs and its own reasoning. The project very quickly becomes a place where different interests and different visions collide.

Product catalog — a comparison of two projects

A product catalog project quickly reveals how an organisation actually operates. It shows:

Paradoxically, the most important part of a catalog project happens before the first screen is designed — in the internal preparation phase.

Setting goals. Defining KPIs. Building a clear ownership structure. Getting your data in order.

Without that, a catalog very easily becomes a project of opinions rather than a tool that genuinely supports the company's growth.

Every organisation today is grappling with the question of how to use AI — including in product catalogs. The problem is that most companies aren't ready for that conversation yet.

Great concepts and large budgets most often fail at a very early stage — at the point of those initial decisions.

That's why our e-book on modernising product catalogs spends so much time on this first stage: preparing the organisation. Because without it, even the best design team and the best technology can't deliver results.

Autentika — Build an Effective Online Product Catalog in 2026

Two online product catalog projects. One delivered on time, the other never launched for five years.

Success and failure. Two online product catalog projects. One delivered on time, the other never launched for five years.

Choosing a CMS rarely feels like a risky decision - until it becomes one at the worst possible moment. When the original developers leave and the documentation proves more of a sketch than a map, a custom CMS quickly turns into a structure only one person fully understands. What once looked flexible becomes a ceiling you keep bumping into.

Moments like this reveal the real risk: not the technology, but choosing a tool that stops evolving the moment its creators walk away. That’s why more teams are moving toward standardized headless CMS solutions - systems built to stay understandable, maintainable, and scalable over time.

Payload is one of them so we’ll look at how it solves the exact problems custom CMS setups tend to create.

How Payload Approaches the Problem Differently

Payload CMS was built to break exactly that pattern. It sticks to tools the market already knows - and it does so with full transparency. It’s open from top to bottom: full code access, no enterprise traps waiting for you down the line. It leans on familiar foundations:

No custom templating language or plugin jungle you’ll regret later. Custom CMS setups rarely collapse overnight. They age slowly and awkwardly. People leave and tools change. What starts as a small shortcut eventually sets like concrete. And one day the system you were so proud of stops being flexible. It starts resisting every new idea you try to introduce.

Take Tekton - a hand-tool maker whose custom CMS had grown so patchy and over-engineered that no one wanted to maintain it anymore. Payload gave them a clean, predictable data structure and an admin panel their marketing team could actually work with. It also removed the dependence on one developer who was the only person able to navigate the old system. The new CMS gave them room to tidy up their product catalog, publish faster and stop wasting time fighting with an old CMS that had outgrown itself.

And on the other end of the spectrum you have brands like Mazda - switching to Payload allowed them to cut operational overhead, simplify content workflows, and let their developers focus on building features instead of firefighting a legacy platform.

That’s really the difference. A Payload project is easy to hand over because everything is readable. You open a schema and the logic is there. If you switch agencies or decide to bring development in-house, new engineers don’t need someone to whisper the “unwritten rules” of the system. They can just start.

Let’s talk about the admin panel. In most custom systems it becomes a whole second app - part UI, part archaeological site - and it falls out of sync the second the team’s attention moves elsewhere. In Payload the panel is generated directly from your schema. Add a field, it's there. Change validation, the UI reflects it. No parallel codebase. No mismatched expectations.

Costs follow the same pattern. A custom CMS seems manageable but becomes costly once fewer developers are willing to go near it. Payload flips that. It uses skills developers already have, so the hiring pool stays wide and sane. And since you can self-host wherever you want (cloud, containers, anything) you avoid the slow creep of SaaS pricing altogether.

From a strategic perspective, predictability is worth more than people admit out loud. Roadmaps shift and teams reshuffle. Companies grow, stall, pivot. A CMS that forces you to stick with one vendor or rethink the architecture every couple of years becomes a risk all on its own. Payload stays out of the way. Versioning is built-in, the admin panel grows as your data grows, and you’re not trapped in someone else’s philosophy. Flexible, yes. But never controlling.

People act as if business security begins and ends with uptime and backups. And sure, that matters. But the deeper kind of security is the freedom to make changes without breaking the foundation. It’s worth pausing and asking a few real-world questions:

With Payload, those problems disappear. And the community matters far more than most teams ever expect it to. With a custom CMS, the moment the original team walks away, you’re on your own. With Payload, things keep moving even when your project takes a pause. You actually see the ecosystem grow instead of freeze. That means:

All of this fits into a bigger shift in the industry. Companies are walking away from custom CMS builds because long-term lock-in just stops making sense - not because they’re lazy. At some point the cost of maintaining a one-of-a-kind system outweighs the benefit of having it. Headless platforms like Payload give you the flexibility teams need without locking you into a single direction. It’s not about going generic - it’s about keeping your options open.

In the end, choosing Payload isn’t really about picking a CMS. It’s choosing a setup that stays clear, maintainable, and understandable long after the original team moves on. A system that doesn’t box your product into decisions made years earlier or force you into rebuilding things that should have stayed simple. It’s the kind of foundation that lets your product grow without dragging legacy problems behind it. Because you’re not choosing a tool - you’re choosing the environment your product will have to live in for a long time.

Payload CMS as a Long-Term Business Safeguard 

This is not just another ordinary blog post – it’s a business proposal, and I will not pretend it’s not. But now since you know it, I want to check whether it’s right for you. No marketing babble – I will get straight to the point.

We’re practitioners who drive change, guiding the implementation of your future vision of success step by step – so if you find yourself in any of those situations:

 and need an objective assessment and recommendation of a plan to remedy them.

 into your organisation, such as automation or AI.

how your business tools and enterprise software compare to the market

 and know that your team's assessment is subject to cognitive error and lacks a broad market perspective.

 – most probably, one of your biggest concerns is how to reduce the risk of bad decisions along the way to archive your future KPIs.

– we may have an answer to those concerns, called Autentika's 

Here’s a short overview of what it looks like:

And here’s a list of companies who already trusted our expertise:

If, after this short introduction, you feel that we fit your areas of expertise and current needs, 

If you need more arguments, let’s dive into the details.

We have been helping companies with their digital products for over 18 years, and our UX/UI discovery process is considered the gold standard in the industry.

We also know that behind every successful enterprise tools transformation lies a 

Before making crucial choices about developing existing solutions or creating new ones, Boards of Directors must first diagnose current challenges and opportunities.

uncover the truth about the current state of tools and processes

 in your organisation and identify needs, problems, money leaks and opportunities for the future.

This profound and highly specialised process helps Boards of Directors set strategic goals, aligning every step with 

Here are examples of projects where we employed our Process and Tools review:

: Replacing a 25-years-old legacy of dozens of apps with a coherent back-office software ecosystem. We designed a set of solutions that support the growth of existing and development of new tools.

: Juki's Customer Portal (CP) serves as an internal tool focused on after-sales service and an ordering platform for customers. The development of CP was driven by the objective to enhance operational efficiency in order placement and streamline global stock level information dissemination.

: A comprehensive and purpose-built application designed exclusively for couriers, featuring an intuitive UX/UI design. With over 400 pages addressing 40 core workflows, this Android-based app seamlessly integrates with users' familiar habits from general applications, ensuring adaptability in diverse conditions.

: A user-friendly app designed for geologists, offering a more accessible alternative to complex tools. This innovation aims to overcome limitations in data analysis, freeing geologists' creativity and enhancing efficiency in the E&P industry.

Let me show you some figures from one of our reviews, which we conducted for an organisation with over 20 different internal digital applications, and more than 300  staff.

The Process & Tools Review is a well-structured and transparent approach that guarantees transformative results. The process involves:

 - Work process modelling - Customer journey mapping - System usability testing

 - User profiling - Qualitative research (i.e.IDIs, video recordings, ethnography, focus groups) - Quantitative research (i.e. data analytics, surveys)

 - industry best practices, market trends (AI included)

 - List of planned features described within the user’s context and covering all identified issues - Scope evaluation and prioritisation

The basis for discussing the future is a thorough analysis of the current situation, identifying problems and creating recommendations for future steps. Of course, Boards of Directors primarily seek this knowledge within the organisation by listening to specialists who work with existing software, analyse data, and produce reports.

However, internal analysis is fraught with many risks, which is why it is often necessary to seek an independent opinion from the market, from people who are confronted with the digital transformation of tools daily and who have developed standards, processes and methods that allow a reliable assessment of the situation.

The advantage of external experts in this process, which is not evident at first glance, is that they are not bound by relationships with people in the organisation.

As a result, they can look objectively at the available tools and processes, ask uncomfortable questions, and hear answers that often don’t have a chance to fall into internal discussions.

An external expert strives for the truth, whatever it may be.

Slawek Wojcik - Head of Relations & Sales at Autentika

Introducing Autentika's Process & Tools Review

For years, we built and maintained our own custom CMS at Autentika. It was tailored to our clients’ unique needs and reflected our ambition to create software that could adapt to the most complex requirements. But over time, our perspective evolved. Today, we want to share why we believe that a ready-made CMS – specifically Payload – is a smarter choice than going with a custom solution developed and maintained by a single company. And why it’s a move your business should consider, too.

Our journey started on the custom side of the CMS spectrum. We decided to build our custom solution as back then, the options available – like WordPress or Joomla – just didn’t meet the standards we were aiming for. So we built our own CMS, named Hitso, and used it as the foundation for nearly every client project.

But developing and maintaining our own platform 

 – each new version of Hitso required major rewrites. Backward compatibility wasn’t feasible, and our clients couldn’t upgrade without significant effort. That made long-term support, security, and performance much harder to guarantee. Over time, this created fragmentation: each client was on a slightly different version, and maintaining those environments became more complex and expensive.

Also, the technology itself moved on, and 

a new generation of CMS platforms matured rapidly.

 JavaScript took center stage. Headless CMSs became the norm. Open-source platforms matured at lightning speed.

And suddenly, our once-innovative platform started to feel… outdated.

As a small company with limited resources, we had always built software around specific client needs. That made it hard to reuse code or scale features across projects. We also began running into the 

 of custom-built systems:  knowledge silos that made onboarding new developers harder, outdated technologies that couldn’t keep up with the market, and a growing inconsistency between different client implementations. Maintaining our platform became increasingly costly and complex.

Eventually, we started losing tenders—because of the technology we were offering.

We knew that moving away from our custom CMS would be a big shift, so we took the decision seriously. We spent months researching modern CMS platforms. We compared features, community support, extensibility, and tech stacks. Our shortlist came down to Strapi, Sanity, and Payload.

 It matched our preferred stack, aligned with how we wanted to build products, and had the kind of modern developer experience that excited our team.

Now, nearly two years later, we’re confident it was the right choice.

Here’s what changed after we made the switch:

 Our team works with a modern tech stack they actually enjoy. This has become a huge asset in recruitment.

 Clients are more confident when we present a well-known, open-source platform instead of a homegrown system.

 Payload is actively developed, backed by a growing community, and used by brands around the world.

 SSO, visual editors, publishing workflows, API-first architecture, A/B testing, version control—you name it. Building all this ourselves just wasn’t realistic.

 With Payload, we benefit from constant improvements, security updates, and best practices shared across a global user base.

Looking back, we only regret not making the switch sooner.

Our journey has fundamentally changed how we think – and talk – about CMS platforms. Today, we’re strong advocates of open-source solutions. And we speak from experience: we’ve been on both sides.

We understand the benefits of custom-built platforms but they’re significantly outweighed by the flexibility, support, and future-readiness of open-source systems. Platforms like Payload come with a solid reputation and a modern tech stack. They’re 

 and supported by active, engaged communities. Updates, tutorials, plugins, integrations, help when you need it—it’s all part of the package.

 by the community. Enterprise features? They’re built in—SSO, complex publishing workflows, rich API support, visual editing tools for content teams, A/B testing, logging, version control, and more.

These are things we simply couldn’t deliver at scale with a custom-built solution.

Beyond the technical advantages, choosing an open-source platform like Payload brings clear business benefits that go well beyond development efficiency.

 There are no licensing fees—initial costs are limited to implementation and customisation.

 Clear documentation and a strong community make it easier to estimate effort and pricing for new features.

 Core functionalities have already been validated by a broad user base.

 Open-source solutions aren’t tied to a single development company.

 Even if one vendor stops supporting the platform, others can step in.

 Open source code can be audited at any time, increasing trust and improving security compliance.

 Payload is actively tested and improved by a wide developer community.

. New capabilities are added regularly thanks to community contributions.

 It’s built to support a variety of use cases—not just one client’s requirements.

 Using pre-built components speeds up project delivery.

. More developers are familiar with popular open-source tools than proprietary platforms.

 Many common problems already have solutions available in forums or documentation.

 Open-source platforms tend to adapt faster to evolving tech trends.

 Easier to integrate with modern technologies and third-party systems.

 Aligns with industry best practices for scalability, security, and maintainability.

By switching to Payload, we’ve gained more than just a new CMS—we’ve unlocked faster growth, better tooling, and a more sustainable future for both us and our clients. Open-source platforms like Payload offer the security, scalability, and flexibility modern digital projects demand. They allow us to focus on what truly matters: delivering exceptional user experiences.

If we could go back, we’d make the switch sooner. But now that we’re here, we’re all in.

Why we switched to a ready-made CMS – and why you should consider it, too

In recent years, even large enterprises have begun adopting startup-like product development philosophies. Proof of Concept (PoC) has long been a recognized method for testing technical feasibility, especially as technology grows increasingly complex. However, the Minimum Viable Product (MVP) approach, while popular in literature and discussions, has been less common in established corporations. The challenge lies in adapting to an iterative, step-by-step product development model within rigid corporate structures that require budgeting, planning, and approvals.

Still, in recent years, more companies have begun embracing 

 on a meaningful scale. In this article, I will explore the 

, sharing Autentika’s experiences with these approaches in two different projects: LISER and Flipatic.

Before we go further, I would like to make a clear distinction between PoC and MVP. Sometimes those terms are used interchangeably, but while both help reduce uncertainty in product development, they serve different purposes:

 serves as an initial experiment to determine 

. It focuses on testing the core hypothesis without considering user experience or business viability. PoC helps answer fundamental questions like: "Is this technically possible?" or "Can we achieve this with our current capabilities?" If a PoC fails, it signals early that a given approach might not be viable, saving significant resources in the long run.

 on the other hand, is a functional version of a product that delivers core value to early adopters. Unlike PoC, 

, providing enough features to validate demand and gather real-world feedback. The goal of an MVP is not just to test feasibility but to determine whether a product has market potential and is worth further investment. It answers, "Should we build this?"

Case Study 1: PoC and MVP approach in a large public sector organization – Liser’s Climate Dashboard

Autentika had the opportunity to implement a structured PoC-to-MVP approach in a project for 

, a publicly affiliated organization in Luxembourg. Given LISER’s conservative nature and structured decision-making process, adopting an iterative product development model was a challenge. However, budget constraints and the need for a rapid release made this approach the best fit.

The project aimed to build a comprehensive 

, integrating multiple data sources, mapping functionalities, analytics, and statistics. The scope was vast, but rather than committing to an extended multi-year development cycle, the organization opted to build a streamlined version first.

Before committing to full-scale development, the team needed to validate the feasibility of processing and visualizing LISER’s complex climate data.

LISER’s climate model produced data in formats that were too large for direct online use, which made real-time interaction difficult.

So, instead of jumping straight into a large-scale solution, we started with 

a small test area to evaluate the system’s capabilities before expanding

. We built a custom data processing pipeline, optimizing raw data into a more manageable and web-friendly format. We also chose a mapping solution that provided a fast and smooth user experience, even when displaying large amounts of information.

The PoC successfully proved that our solution could handle LISER’s complex datasets at scale. This cleared the path for the MVP phase, where we focused on delivering a functional product.

With the PoC proving feasibility, the focus shifted to building an MVP that delivered immediate value while staying within budget and time constraints. Instead of committing to a long, multi-year development cycle, LISER opted to launch a streamlined version first, ensuring early feedback and stakeholder buy-in.

Instead of implementing every planned feature, we focused on mapping functionalities, analytics, and statistical tools that would provide the highest value to users. A working prototype was built and deployed within three months, allowing LISER to collect early user feedback.

A functioning dashboard that delivers real value while paving the way for future iterations.

Another example of Autentika’s experience with PoC and MVP comes from 

, a platform for transforming text articles into video content using AI.

The Flipatic project began with a fundamental hypothesis: 

Can we automate the conversion of written content into engaging video narratives?

 At the outset, the primary focus was on technical feasibility. The team experimented with different AI models, tool integrations, and processing techniques without considering the end-user or business model. This phase was an engineering experiment – a PoC to validate the idea.

After several weeks of testing, we confirmed that 

. The PoC phase established a clear technical foundation, proving that an AI-driven transformation process could be executed at a high-quality level.

With the technical feasibility confirmed, we shifted towards building an MVP. Through structured workshops, the team outlined a vision for the full-scale product while carefully extracting the core functionalities for the MVP. Rather than attempting to include every possible feature from the start, 

we prioritized the essential transformation workflow

 —the ability to convert articles into videos effectively.

By releasing an MVP, we were able to engage with real users, gather critical feedback, and refine the roadmap. Interestingly, some initial assumptions about user needs proved incorrect, while overlooked features turned out to be crucial. 

Without an MVP, these insights would have come at a much higher cost and risk

At Autentika, we observe that PoC and MVP methodologies are gaining popularity among large enterprises. Even when clients do not initially consider these approaches, we frequently propose them as strategic options.

A common concern in the industry is that MVP and PoC might not always align with a service provider’s short-term financial interests – after all, why encourage a phased approach when a client could commit to full-scale development from the start? However, we believe that advocating for these methodologies fosters trust, transparency, and long-term success.

The fundamental advantage of PoC and MVP is 

. In the worst-case scenario, a PoC failure saves companies from investing heavily in an unfeasible idea. Likewise, an MVP prevents unnecessary spending on features that might not matter to users.

At Autentika, we apply these principles not only in client projects but also in our own product development. Our experiences with Liser and Flipatic confirm the practical benefits of this approach – delivering value faster, reducing uncertainty, and accelerating innovation. For businesses seeking to navigate complex digital transformations, embracing PoC and MVP is no longer optional – it is essential.

If you would like to explore whether an MVP or PoC approach could benefit your next project – let’s connect, and we’ll show you what we can do for you!

MVP vs. PoC: The smarter path to product development

Newsrooms initially approached AI with caution, fearing job displacement, misinformation, and the ethical dilemmas posed by automation. However, as the technology matures and its applications become more refined, the conversation is shifting. Instead of fearing AI, many media organizations are now embracing it as a tool to enhance journalism, improve efficiency, and unlock new creative possibilities. As we enter the first half of 2025, it’s time to assess where newsrooms stand with AI.

 of over 1,900 employees across 19 EMEA organizations reveals a growing optimism about AI in newsrooms. While 

57% of senior leadership express enthusiasm for AI

 – likely due to cost-saving potentials – editorial teams remain the least optimistic, with only 36% showing positivity. Their concerns center around copyright infringement, AI hallucinations, and editorial control. However, an increasing number of journalists and editors recognize that generative AI can save time and effort when used effectively.

In the early days of AI adoption, skepticism dominated newsrooms. Journalists engaged in cautious and unstructured experimentation, using AI primarily for transcription, data analysis, and automated news summaries.

Today, we see a marked shift. AI is more and more often viewed as an essential tool in a modern newsroom. Media organizations are 

transitioning from experimentation to structured

 AI training programs. For example, the Financial Times launched the 

Exclusive insights from our work