How to Choose the Right Outsourcing Partner f...
As an IT company with over 25 years of experience developing diverse software solutions, we have repeatedly faced the challenge of building catalogs. Over time, we’ve worked with marketplaces, individual online stores, document processing systems, and even large-scale delivery service. Almost every project had one recurring need: a catalog service.
Businesses across industries often need a reliable and flexible way to organize and present information – products, services, or structured data. The question is not whether a catalog is needed – it almost always is. The real challenge lies in defining what kind of catalog serves businesses best.
In over two decades of projects, we had worked on dozens of catalogs – for marketplaces, e-commerce, document management systems, logistics platforms, and more. And in every single product, there was always some form of catalog:
This recurring pattern led us to question our own approach and examine the deeper issues beneath the surface. What began as technical frustration evolved into a project to solve not just our own challenges, but those faced by developers everywhere. Here’s how that journey unfolded.
With every new project, we’ve always tried to do the same thing: listen carefully to our clients, understand their needs in detail, and deliver exactly what they expect.
Of course, there were times when we felt we could see a better solution – but it wasn’t always possible to convince a client to take a longer path than they were ready for.
That experience made us realize: if we truly believe in certain ideas, perhaps we should invest in them ourselves and build a product that can be reused and quickly customized for different business needs.
And so, unexpectedly, we found ourselves on the other side of the table — as clients.
Working with brilliant developers who could deliver fast, high-quality results, we experienced the process from a different perspective. Instead of openness to explore our needs, we often encountered resistance. This was eye-opening and made us reflect on our own approach.
Through these experiences, we’ve learned a hard lesson: if you start building a catalog from scratch for each new project – ignoring past experience – you inevitably hit the same wall. The system lacks flexibility, fails to cover evolving business scenarios, and quickly becomes a bottleneck.
Businesses grow faster than the software meant to support them, and nothing is more frustrating than watching technical limitations slow down real opportunities.
Every time, we built catalogs from scratch. Sometimes we refined older versions, but in the end, we always started over. Which made us ask a simple but powerful question:
👉 Why are we reinventing the wheel every time?
This question became our starting point. As we reflected on our years of building catalog systems, we realized that we weren’t just facing a technical challenge – we were looking at an opportunity to fundamentally rethink how catalogs should be approached. Our setbacks could become the foundation for something better.
From our own experiences and from challenges we’ve seen others face, we came up with the idea of creating something like a “handbook for catalogs.” Not as a set of rules, but as a way to collect and share the practices, patterns, and lessons that have worked for us so far.
At the same time, it’s also a chance for us to learn new approaches we might not know yet.
But since we live in the real world, theory alone is not enough. That’s why we decided to transform our accumulated knowledge into a practical solution – an open-source catalog project.
We realized we already had the expertise and the experience:
So why not create a flexible catalog product – one that can serve as a component in almost any system? A product where developers (or businesses) can:
Of course, writing a catalog isn’t rocket science. Any skilled developer can do it. But doing it again and again is a waste of time. By making our solution open source, we want to:
We’re not just building a tool – we’re building it together.
Our catalog solution follows a modular architecture designed for flexibility and scalability. At its core, the system consists of well-defined components that handle different aspects of catalog management:
Data processing architecture
The system uses a job-based approach with separate import and export workflows:
Import process:
Export process:
This architecture provides several key advantages:
The modular design allows developers to replace or extend specific components without affecting the entire system. For example, you could swap the FlatFileItemReader with an API-based reader, or replace the validation logic with your own custom rules.
With this open-source catalog project, we’re trying to create something practical that grows through real-world use and input from other developers.
What we’re trying to do:
We’ve put the first version on GitHub, and now we need your input:
Different perspectives make for better software. Your experience might help us see things we’ve missed.
👉 https://github.com/setronica-dev/unify-catalog/tree/prototype
We hope this saves you time and helps your projects grow. Let us know what you think!
