OBIBOOK: from a broken import to a rebuilt book catalogue

Starting point: a broken import in an existing application

The first version of OBIBOOK was built by another provider. In 2022, we were asked to repair it because the import did not work correctly. This affected a key process: without a reliable import, maintaining a large book catalogue was difficult.

The earlier application also needed visual and technical fixes. It did not work properly on mobile devices, which made the catalogue difficult to use away from a computer.

We repaired the earlier version first

During the first stage, we fixed the reported and identified faults. We rebuilt the large CSV file import, improved the interface, and corrected how the application worked across different devices.

After this work, the import and the other elements covered by the project worked correctly. The application could also be used on phones and tablets. This stage stabilised the system and helped us understand the client's real workflow before a larger rebuild.

The next stage: a complete system rebuild

From 2023 onward, we rebuilt the application in Laravel. This was more than a visual refresh. We created a new technical foundation for the catalogue, imports, users, and book lists. We also introduced smaller improvements based on the client's day-to-day work.

The cooperation continues. When another part of the workflow can be simplified, we implement the agreed change and suggest practical directions for further development.

How OBIBOOK supports catalogue work

OBIBOOK brings several steps together in one system:

1. Book data is imported from CSV files.
2. Users can browse and search the catalogue by book, category, and publisher.
3. Logged-in customers create their own book lists.
4. Customers make manual corrections to those lists and send them to Ms Kinga.
5. The system also makes it possible to export and hand over prepared lists.

OBIBOOK is not an online store and does not handle sales. Its role is to organise the catalogue and prepare lists used in the next stages of the client's work.

If a similar process needs to receive or transfer data between different sources, see our system integrations and API services.

Result: a working process on different devices

The most important result of the first stage was restoring the import and the other repaired elements to proper operation. The application also began to work correctly on mobile devices.

The later rebuild gave the client a new foundation for developing the catalogue and working with lists. We do not quote time savings or sales impact because no approved measurements are available. What we can confirm is a qualitative change: a process that had not worked correctly was repaired and then moved into a rebuilt system.

Client feedback

Kinga Jambroszczak, Obibook

When does a similar repair or rebuild make sense?

An older application does not always need to be replaced immediately. It is often better to check first whether a critical problem can be repaired safely and the main process restored. A complete rebuild becomes more reasonable when:

• failures keep appearing in different parts of the system;
• the application does not work correctly on the devices people use;
• the current technology makes development and maintenance difficult;
• the company still needs the data and workflow, but the existing solution is a poor foundation for further changes;
• isolated fixes start taking more time than an organised rebuild.

With OBIBOOK, we first stabilised the earlier version. We moved to a complete rebuild only after learning how the process worked in practice. This reduces the risk of designing a new system around assumptions alone.

What to prepare before handing over an application

At the beginning, we mainly need to know what does not work and which process it blocks. The following are also useful:

• a sample file without confidential data;
• a description of the expected result and the current error;
• information about who uses the application and on which devices;
• access to the code and documentation, if available;
• a list of changes made in the past.

Passwords, customer data, and production files are not needed for the first conversation. You can use our application handover checklist to organise the basic information.

Do you have an application that needs repair or rebuilding?

Tell us what does not work today, which process is affected, and whether you want to repair the current solution or are considering a rebuild. We will use this information to identify a safe first step.

Describe your application problem

See also application modernisation and takeover, PHP and Laravel development services, system integrations and APIs, and other case studies.