SABSUS: how I came to the idea of one system instead of chaos across dozens of services

Where the real understanding of the problem began

The deeper I went into real business operations, the more clearly I kept seeing the same pattern. Owners had accepted constant manual work between systems as normal. Someone moved clients from messages into the CRM by hand. Someone copied orders from a website into the POS. Someone checked stock in a separate place. Someone forwarded information from one program to another. Analytics were stitched together in spreadsheets. On paper, all of that was called automation. In practice, it was normalized chaos.

You notice it most in companies with many roles and many channels. Restaurants, retail, dark kitchens, delivery, services, rentals, digital products — the same problem appears everywhere. Different people see different parts of the same reality, but the business has no single core holding everything together.

At some point I understood something simple: the issue is not that businesses lack software. They actually have too much of it. The issue is that all responsibility for connecting processes falls on people — the owner, the manager, the cashier, the admin, the marketer, the developer, anyone except the system itself.

That was the point where SABSUS started to take shape for me.

Why I did not want to build just another CRM or just a POS

From the start, I did not want to follow the obvious path. It would have been easier to make a standalone CRM. A separate POS would also have been easier. I could have picked one module, packaged it nicely, and sold it as a finished product. But that still would not solve the real problem.

A real business does not live in modules. It lives in roles, events, and processes.

The owner sees the company as a whole. The cashier works with the order, payment, customer, and promotions at the same time. The kitchen sees a task to fulfill, not just a line on a receipt. The courier needs route, confirmation, statuses, and a connection to the customer. The sales manager needs more than a lead card — they need the full communication context, deadlines, scripts, and next step. The warehouse does not deal with abstract numbers; it deals with receiving, transfers, stock, suppliers, inventory, and documents. And the client should never have to think about how many systems their order passes through inside the company.

That is why SABSUS was never designed as a bundle of modules. It was designed as a single environment where all of these roles have their own interfaces but still operate inside one logic.

How the architecture of SABSUS started to form

I kept asking myself the same question: what does each role actually see, and what does it really need at that exact moment?

That is how an architecture emerged in which the same platform could give completely different workspaces to different participants in the business without breaking apart into separate products.

The owner assembles the company: locations, staff, permissions, branding, payment methods, warehouses, delivery zones, documents, finance, and settings. The cashier works in the POS, accepts orders, changes compositions, applies bonuses, deposits, and discounts, sends items to production, and closes the payment. The kitchen gets a production interface where an order is treated as a task with stages, comments, and timing. The warehouse sees actual inventory movement, deliveries, write-offs, receiving, inventory counts, and related documentation. The supplier is not a faceless note in the system but a full participant with its own catalog, offers, documents, and messages. The courier gets an environment for routes, confirmations, customer communication, and statuses. The client gets an account, an app, a catalog, orders, bonuses, notifications, digital products, and the full history of interaction with the brand.

The key point is not the number of screens. The key point is connectedness. None of these parts exist in parallel. They are tied together by data, events, and shared logic.

Why everything starts not with the product, but with the business framework

One early thought shaped the product more than almost anything else: if the foundation of a company is assembled badly, no beautiful interface will save it later.

That is why in SABSUS a business is not merely registered. It is assembled.

A company inside the system is not just a name and a logo. It includes languages, tax parameters, currency, addresses, operating scenarios, sales points, payment methods, access permissions, work modes, accounting settings, and everything else the rest of operations depends on.

I also spent a lot of time thinking about locations. In real life, one location can be a restaurant with dine-in, delivery, and pickup. Another can be a production site. A third can be an online store. A fourth can be a dark kitchen. If the system does not understand that at the architectural level, everything after that turns into compromises, workarounds, and endless limitations.

I wanted every location in SABSUS to be a living unit with its own schedule, address, warehouse, delivery zones, order fulfillment methods, print settings, payment rules, receipts, service fees, and everything else that truly affects the way the business operates.

Catalog: the place where ordinary systems usually break

A lot of products still treat an item as a simple card: name, price, photo. In reality, that is almost never enough.

When a business truly operates, it has standard products, services, rentals, ingredients, semi-finished goods, tech cards, packaging, modifiers, digital products, schedules, staff assignments, availability by channel and location, different fulfillment logic, and different cost structures.

That is why the catalog in SABSUS was designed to go much deeper from the very beginning.

An item can be a standard product. It can be a service with booking logic and time slots. It can be a rental with a reservation period and return flow. It can be an ingredient with stock and write-offs. It can be a tech card with composition, gross, net, and cost. It can be a semi-finished good used in production. It can be a digital product that the customer receives after purchase as a file, link, page, video, or course.

It was important to me that the system describe not just a storefront, but the real nature of what the business sells, produces, books, delivers, and controls.

Customer layer: not just an app, but an extension of the entire platform

Once you have an internal core, the next question is always the same: what does the customer see on the other side?

Here I definitely did not want to build just a catalog and a cart. That is too weak for a business that wants to build its own ecosystem.

In SABSUS, the customer sees more than products. They see the brand, their active orders, statuses, bonuses, deposit, notifications, addresses, history, favorite items, digital products, documents, and support. They may interact through a mobile app, a web interface, a self-service station, a QR menu, an order status screen, and different surfaces of the same system.

It was essential for me that the customer experience not be cut off from the company’s internal processes. If an order has gone to the kitchen, that is reflected. If delivery is active, that is reflected. If there is a loyalty program, it is built in. If someone bought a digital product, they receive it inside their own environment, not somewhere outside the system.

POS: not a payment window, but the operational center of the location

If you look at many checkout solutions, you quickly see how often POS is treated too simplistically — as if its only job is to take money.

But in real operations, the POS is where order, customer, catalog, promotions, inventory, kitchen, payment, history, and staff all intersect. Mistakes there are expensive.

That is why I built the POS in SABSUS as a full order control center. The employee signs in with a PIN, opens the shift, sees the cash balance, works with the order, changes compositions, applies promotions and bonuses, uses deposit balance, adds comments, sees the customer and history, tracks statuses, can split the payment, accept a partial payment, send items to production, print the receipt, and keep the order alive until completion.

It also mattered to me that the system not become useless when the internet has issues. A real business should not stop just because connectivity disappears somewhere.

Production and kitchen: an order should be a task, not an abstraction

Another area I never wanted to treat superficially was kitchen and production.

Very often, once an order is placed, everything becomes a black box. The cashier creates the order, then it goes somewhere, and the kitchen lives its own separate life. I never liked that model.

In SABSUS, the production interface was built so the employee sees the order as a task: number, composition, time, notes, stages, status, priority, comments, photos, recipe, tech card — everything needed to actually fulfill it without losses or confusion.

And this is not only about restaurants. It is about any fulfillment zone: kitchen, bar, packaging, production, pickup, service, or rental assembly.

Warehouse: not stock for the sake of a checkbox, but real control

If sales and production are deeply built, but the warehouse still lives as a separate spreadsheet, chaos simply arrives a bit later.

That is why the warehouse block was always critical for me. In SABSUS it is not limited to stock counts. It includes receiving, deliveries, supplier requests, transfers, returns, inventory, write-offs, documents, invoice recognition, label printing, purchase history, and everything else needed to turn accounting into real control.

I wanted the warehouse employee to live inside one digital loop, not jump between invoice photos, chats, spreadsheets, and separate programs. When a delivery arrives, it should immediately connect to the supplier, the document, the item, the stock, and the purchasing history.

This is the level where a business starts to feel the difference between 'we track something' and 'we truly understand what is happening.'

Suppliers and purchasing: move them out of the gray zone

In most companies, suppliers still live somewhere outside the main system. Prices are in chats. Offers are in PDFs. Documents are in email. Confirmations happen by phone. New items are always 'we’ll send them later.'

That is inconvenient even at a small scale. At a serious scale, it becomes dangerous.

That is why in SABSUS a supplier is not a note in the system. It is a full entity with its own catalog, offers, orders, documents, messages, and balance. A reseller follows one logic. A classic supplier of ingredients or packaging follows another. But in both cases, the supplier is embedded into the core process instead of existing somewhere next to it.

Delivery and courier: the last mile must also be part of the platform

The last mile exposes weak systems very quickly. When you have only a few deliveries, you can solve everything manually. Once the volume grows, that manual mode starts hurting speed, quality, and customer experience.

That is why I built a dedicated environment for the courier: routes, map, statuses, a call to the customer, photo confirmation, tasks, shifts, vehicle types, navigation, and order acceptance logic. It mattered to me that the courier not operate like someone who received an address in a chat, but like a full participant in the operational process.

For the customer, this is one of the most sensitive stages of all. Everything that happened inside the business before that gets judged by the final minutes of interaction. That is why delivery was never just an extra feature to me.

CRM: not a list of cards, but a real sales engine

By the time I got to the CRM part, I already knew exactly what I did not want. I did not want another pretty board where leads are just dragged between columns.

A real CRM should help you sell, not just store contacts.

So inside SABSUS, CRM was built much deeper: pipelines, distribution rules, responsible managers, working hours, first-touch SLA, timers, follow-up scenarios, archive, checklists, scripts, qualification branches, message templates, tasks, manager training, and guidance for the next step.

And most importantly, it is connected to the rest of the channels. A lead can come from the website, a form, Instagram, WhatsApp, Telegram, email, ads, or comments. The system should not just save that lead into a card; it should place it into the sales process without losing the context.

Communication and marketing: gather scattered channels into one story

Communication is another area where most companies fall apart.

Email is separate. Social media is separate. SMS is separate. Push is separate. Customer history is separate. Marketing is separate. Sales are separate.

I wanted all of that to be gathered inside SABSUS into one layer. The business should be able to work with promotions, customer segments, bonuses, discounts, banners, campaigns, and messages not as a disconnected toolbox, but as a single communication loop.

That is why integrations with email, SMS, Instagram, WhatsApp, Telegram, Facebook, and other channels matter so much. If a person has already interacted with the business, written a message, bought something, received bonuses, joined a campaign, or submitted a request, all of that should become one connected story instead of being lost between different dashboards.

Flow: the module that connected everything together

At some point I realized that no matter how many interfaces and modules a platform has, every business eventually runs into its own unique scenario. Every company has its own rules, triggers, reactions, workarounds, and non-standard processes.

That is exactly why Flow became one of the key modules in SABSUS for me.

In essence, it turns the system from a set of powerful interfaces into a programmable platform. Flow can react to events, run on schedule, accept external webhooks, read and transform data, call external APIs, create tasks, change statuses, send messages, work with payments, publish content, invoke AI services, and build multi-step scenarios tailored to a specific business.

This was a critical step. Without that kind of flexibility, even a strong system eventually becomes limiting. I wanted the opposite: a platform a business could build its own logic on top of, instead of a platform the business has to adapt itself to.

White-label: not about swapping a logo, but about owning your environment

The white-label topic is especially important to me.

I never saw white-label as a simple replacement of colors and logos. For me, it means something bigger: a business should be able to own its digital space — its brand, its customer experience, its data, and its interaction scenarios.

When a company depends only on external aggregators and third-party platforms, it is always vulnerable. It does not fully control the customer journey, communication, or margin. That is why white-label in SABSUS is part of a broader idea: not to give a business someone else’s dashboard, but its own infrastructure.

What pains SABSUS solves in practice

Put simply, SABSUS solves several systemic problems that usually come as a package.

First, it removes fragmentation — the situation where a company has ten services and no real center. Second, it reduces the amount of manual work between roles and channels. Third, it gives control back to the owner because the data stops being scattered. Fourth, it makes scaling possible without the feeling that every new location only creates more chaos. Fifth, it gives the business its own digital environment instead of forcing it to depend on someone else’s platforms. And finally, it creates a reserve of flexibility so that new scenarios do not turn into a brand-new technical project every single time.

Why I keep building SABSUS

For me, SABSUS stopped being just a piece of software a long time ago. I see it as an operating system for business — a digital infrastructure where you can assemble a company, build sales, set up production, connect warehouse, delivery, communication, marketing, documents, suppliers, customers, and automation.

Put in simple human terms, SABSUS is my answer to the chaos I kept seeing in modern business.

I did not want to build a beautiful shell around old problems. I wanted to change the logic itself — to let a business owner stop living between ten different services and start operating inside one system where everything is connected, understandable, and manageable.

That is exactly why I keep building SABSUS.