How the Work on the FoodSoul System is Organized: From Idea to Result

We value the trust of our partners and therefore strive to be as transparent as possible. In this article, we will explain how our team is organized, how ideas are transformed into features, how we set priorities, and what happens behind the scenes when something goes wrong.

FoodSoul is a living system

FoodSoul is not just an app. Behind it lies a vast infrastructure: CRM, data storage and protection, website and mobile app templates, and thousands of partner restaurants, each with its own needs and workflows.

We are constantly listening: we gather ideas from partners through support, direct communication with clients, and from our own IT department analysts. All of this is accumulated in a backlog—a constantly updated list of tasks that forms the basis for the product development roadmap.

How the team and workflow are organized

Several groups of specialists work on FoodSoul, each with its own area of responsibility and its own logic of interaction with the others.

Support is the first line of contact with partners. They receive requests, understand the essence of the problem, and either resolve it on the spot or pass it on to a specialist who knows the relevant part of the system.

Second-line specialists are engineers with deep expertise in specific modules: integrations, mobile apps, CRM, payments. They determine whether a request is a feature of the functionality or a real error.

Analysts collect and structure partner requests, assess how much a change is in demand and how it will affect other clients before a task moves into development.

Developers and testers implement tasks and check them before release—from minor tweaks to major functional improvements.

Project managers keep priorities in focus: they monitor the backlog, distribute tasks among teams, and ensure that important issues are not lost among current tasks.

Work is organized cyclically: the team regularly reviews the backlog, evaluates new requests and suggestions, plans upcoming tasks, and monitors the status of those already in progress. This rhythm allows us to keep track of both urgent problems and long-term product development, while maintaining predictability: a partner can always find out through support at what stage their request is.

How we set priorities

When a problem arises, we act according to one of several scenarios.

Widespread outage—an error encountered by several clients simultaneously within a day or a few hours. This is the highest priority: testers and developers respond immediately.

Critical bug for a single client—if an error directly affects a partner’s revenue or reputation, the priority is just as high. We allocate key resources and resolve the issue as quickly as possible.

Standard bug—a request received by support that does not appear catastrophic. It is handled by a second-line specialist who knows the system well. There are two possible outcomes: either it turns out to be a feature of the functionality that was not considered, in which case the client is given an explanation; or the problem is real, in which case it goes to the project manager, is logged in the task system with a priority and responsible person, and is implemented in turn. The support specialist tracks the status and informs the client when the task is completed.

Minor bug—an error that does not affect the system’s operation but needs to be fixed: a typo, a misplaced interface element, an incorrect button color. Such tasks are addressed when there are no higher-priority requests from the categories above.

Suggestions—we closely monitor what partners request. When the same request comes from several clients, its priority increases and we move it to analytics. Any change affects all partners at once, not just the one who requested it, so before implementation we gather feedback from different clients to ensure that an improvement for some does not create inconvenience for others. This is an extra step, but it makes the final decision more balanced.

Why bugs occur

The development of any complex product is such that errors are a regular part of the process, not an exception. Here’s what makes it complex.

The system is growing. The more features, integrations, and usage scenarios, the more points where different parts of the system interact. The team tests the most typical scenarios, but it is physically impossible to cover all combinations in advance, even for the most experienced team.

Each partner uses the system in their own way. Thousands of establishments mean thousands of unique workflows. User behavior in real conditions is always richer than can be anticipated in test scenarios, and some deviations only appear with live data.

One change affects another. When a developer improves one module, it may impact related functionality. The larger the system, the longer the chains of dependencies between its parts, and the more carefully each change must be checked.

The environment is constantly changing. Browsers, operating systems, and third-party services we integrate with are updated. What worked yesterday may behave differently after an update on the side of a third-party company, and we monitor such changes to respond quickly.

Requirements are clarified in the process. Sometimes a feature is implemented exactly as intended, but real-world use shows that the idea needs refinement. This way, the product becomes more precise with each iteration.

We treat this as a normal part of the growth of a complex system and are constantly working to make it more stable, faster, and more convenient for every partner—through deeper testing, a clear team structure, and ongoing feedback from clients.

If you encounter a problem or want to share an idea, write to FoodSoul support. Every request reaches the right specialist and is never lost. We are here for you!

Best regards,

Project Manager FoodSoul