The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Enterprise Software
How many institutions, branches and screens will share the same system? That number is settled before anything else at this scale, because it decides where the line between one institution's records and the next is drawn. CRM, ERP, management systems, process tracking, bookings and field service are separate services under this roof, and this page answers the question they have in common.
Enterprise software is what a business needs at the scale where several institutions, branches and screens share one system. The first decision at that scale is where the data divides: each institution signs in through its own domain, sees only its own records, and bringing in another one is a definition rather than a second installation. Vipkurum runs seven education institutions that way on a single system.
At Vipkurum seven education institutions use the same software without sharing an address. Each one opens under its own domain and carries its own brand. Student, parent and payment records belonging to one institution stay closed to the next. Bringing another institution in means writing its definition rather than repeating an installation, which is what how multi-tenant systems are built walks through.
AlgoKlima gives one system two faces. The office works in a panel; the field works in a phone app, and both read and write the same record. The app does not stop when the signal does: the technician keeps recording, and whatever is waiting reaches the office panel once the connection is back. Nobody keeps a second program for the other half of the job.
At AlgoCar the service record and the commercial record close in the same place. The cost and the revenue of one job never have to be pieced together from two reports at month end.
The services under this roof have scopes of their own. CRM holds the relationship with the customer: the appointment, the step in the plan, what is left in a package, the history of the service given. ERP holds the stock movement and the invoice that come out of a work order, and its scope stops at operations, stock and accounting. Management systems hold the internal rule, the capacity and who is allowed to see what. Process tracking follows recurring work that has a closing record. Two narrower headings sit beside them: an appointment booking system for the rule behind a booked hour, and field service software for the record a technician opens at a customer’s address. Which of them fits you is something we work out together in the first conversation.
One technical footing sits under all six. We do not choose a new set of tools per project; we choose the set we can still maintain years later. When another institution joins, or the field app gains a screen, the same team keeps the maintenance, and whoever takes your system over learns your records first rather than a new toolset.
What changes when the institutions multiply, and what stays as it is:
At Vipkurum, seven education institutions open under their own address and their own brand, and the name of the software never appears on a user's screen.
Adding one more institution means writing a definition. No second copy of the system is stood up, and the maintenance stays in one place.
AlgoKlima's office panel and field app read and write the same record. A technician closes the job where there is no signal, and the entry reaches the office panel once the connection returns.
At AlgoCar the service record and the commercial record sit in the same system, so the cost of a job and its revenue are not reconciled across two programs.
Student, parent and payment records stay inside the boundary of the institution they belong to. That boundary is how the system is set up, not a view switched off on a screen.
Nothing goes into your system that the team maintaining it does not already know. AlgoKlima and AlgoCar are our own products, built on that same footing, and we work on it every day.
Every project goes through the same four stages: planning, architecture, modelling, development.
See our process
Seven education providers work inside one platform, each signing in at its own domain and appearing under its own name. Timetables, exams, students, guardians, payments and reporting all live in the same place.
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
What a database keeps, and where relational and document stores part ways. Vipkurum holds both at once; in Secretum, a product we are still building, the record sits on the document side.
Seven separate installs, or one core? When the tenant boundary is a property of the data rather than a UI filter, adding an institution becomes a record instead of a deployment. Vipkurum shows how.
You are weighing a server or SaaS abroad and the question is heading to a lawyer. What you bring is not an opinion but one list: which field goes to which machine, and which of them name a person.
Answers made of years, counts and adjectives will not tell companies apart. Questions whose answer is an address that opens today, a named boundary, or a place and an order, and how to check each.
They can. Each of your branches signs in from its own domain and shows its own brand; the name of the software stays out of sight. Vipkurum runs seven education institutions on one system, each under its own domain and brand, and that separation is how the platform was set up rather than a display option. The school platform case on this page shows how an institution is defined.
It cannot. Nobody at the institution next door can list your student, parent and payment records or export them. Vipkurum keeps the records of seven institutions in one system, and one institution's records never enter another one's query, because the line is drawn in the records themselves. The article on how multi-tenant systems are built walks through where that line goes; it is a good place to start for your own institutions.
They can. The job your technician opens on site is the job your office sees in its panel, so nobody re-enters the day's work in the evening or squares up two lists. AlgoKlima keeps recording after the signal drops, and the waiting entries reach the office panel once the connection is back. The field service case on this page describes the route a record takes to the office.
It does not. Your next branch is added to the system that already runs as a definition, so there is no second server to stand up and no second copy to maintain. Vipkurum attached seven institutions this way, and none of them needed an installation of its own. Put the number of branches you expect into the scope step of the quote form and we plan the system around it.
It is, once the marking of an exam has to be your institution's own decision. An assessment rule written into the software cannot hold European and Turkish criteria in the same exam. With the rule defined by you instead, both criteria sit in one infrastructure and the choice stays yours. Vipkurum lets each institution define the assessment type of its own exams, and nobody waits on a code change to do it. You will find that definition in the school platform case further down.