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.
System Architecture
Where will the data divide, what will each record attach to, which screens read from a held copy, and how many interfaces will hang off one system? Reverse any of those later and everything already recorded has to be re-attached.
System architecture is what gets decided before any code: what a record attaches to, where the data divides, how many interfaces one system carries. Each is settled in the data model rather than the interface, and when several institutions share one system, each institution's data stays inside its own boundary. Vipkurum draws that boundary at the domain level, and Tahlil.com hangs a patient site, a physician panel and a mobile app off one system.
At Vipkurum the institutions share one piece of software but not one address. Each opens under its own domain, carrying its own brand. An institution that buys a ready-made panel usually appears under the software vendor’s name; here the requirement was the reverse.
That requirement is not an interface setting. It is the kind of choice we mean when we say architecture is measured by the cost of undoing a decision. The boundary sits in the data model: one institution’s student, guardian and payment records are never visible to a neighbouring one. Access is part of how the record is defined rather than a filter applied on the screen. A teacher, a guardian and an administrator reach the same timetable at their own level.
The second decision is how many interfaces hang off the system. On Tahlil.com a patient enters values on the site, the physician writes the interpretation in the panel, and the notification reaches the phone through the mobile app; all three sit on a single system, with no second data model written per interface.
The third is what a record attaches to. AlgoKlima writes warranty and maintenance history against the device rather than the customer, so several air conditioners at one address never share a file, and a unit that changes hands keeps its history. That choice is not a setting anyone reverses lightly: undo it later and every record collected until then has to be re-attached.
This page describes systems built from nothing. If you already run working software, the job becomes a takeover and the first question changes to what may be touched and what may not. We describe that work under software consulting.
The decisions we settle before a line of code is written:
When several institutions share one system, each enters through its own domain and student, guardian and payment records stay inside that institution's boundary. This arrangement is what the term multi-tenant describes.
Whether service history is written against a person, an address or a device is settled before the schema exists. Reversing that later means re-attaching everything already recorded.
A teacher, a guardian and an institution administrator reach the same timetable record at their own level of access. Permission is part of how the record is defined, not a view switched off on a screen.
Which screens are served from a held copy and which go to the database is settled before the first record exists. On Vipkurum a frequently opened screen comes from the copy, and only a read with no copy reaches the database.
Tahlil.com hangs three interfaces off one system: the patient site, the physician panel and the mobile app read the same record, and no second data model is written per interface.
The naming and folder scheme files will live under is fixed at the start; a layout imposed afterwards turns into a migration.
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.
Patients type in their lab values and a physician writes the reading. The public site takes the values, the doctor's panel is where the interpretation is written and approved, and a mobile app tells the patient the moment it is ready.
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.
A proposal calls the system scalable and never says what will grow. Organisations, branches, pages and a longer catalogue each strain a system elsewhere, and one answer does not fit another.
Ask what a workflow is and you get a drawing back. What tells you where a job is waiting is the record: the state it sits in, and the party allowed to move it on.
An API is an agreement between programs. A second program touching the record forces the gate: a patient's phone at Tahlil.com, a technician's at AlgoKlima. We are building QRVizit without one.
A proposal lists two line items, frontend and backend, and nobody says which work falls where. One half draws the screen, the other holds records and rules; a rule in the wrong half looks right.
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.
Every rebuild gets the same advice: switch frameworks. The real question comes first — is the output identical for everyone who asks? One answer prerenders the page, the other renders it per request.
One brief, several quotes that refuse to line up, and no document saying which quote priced which job. The three lines a brief tends to leave open, and the one sentence that closes each of them.
The software ticks every line on your list and the work still does not fit. How to bring the two things a developer asks about, the conditions of the work and the record, to the first meeting.
A decision is architectural when undoing it is expensive, and timing sets the price. Boundary sentences, derived records, inherited limits and the three calls we bind before the first line of code.
An OMR device sits in one office; branches ship their answer sheets to it and wait. Move the reading from the device's optics to the form image, and every branch that can scan can score.
Backups are taken; in how many places does your record sit right now? In AlgoKlima, which we run ourselves, a record opened out of coverage sits on the technician's phone alone until signal returns.
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.
A model produces output; someone still answers for it. From lab-result interpretation to exam scoring, our projects show where the approval step sits and why oversight is a founding decision.
The wait a user sees comes from the request the job never left. One flow step from Secretum, which we are building now: what gets queued, where the file lands, how the result returns.
If "who maintains this?" is still an open question on launch day, the decision was skipped, not deferred. How the maintainer choice shapes stack, handover, and build order.
Code and files sit on your disk, yet which file belongs to which record is known only to whoever read the code. The system runs; you cannot rebuild it. The handover list is the list of that gap.
We draw it at the domain level: each institution enters through its own address and appears under its own brand. Your student, guardian and payment records never reach a neighbouring institution, and access is part of how the record is defined rather than a filter applied to a screen. Vipkurum runs 7 institutions on one system, each behind its own domain; the case page shows how the boundary was drawn.
Two cost the most: what a record attaches to, and where files are kept. Reverse the first later and everything you have collected has to be re-attached; leave the second unsettled and putting a layout in place afterwards becomes a migration. AlgoKlima writes warranty and maintenance history against the device rather than the customer, so several units at one address never share a file and a unit keeps its history when it changes hands.
We can, but taking over a running codebase is a separate engagement and not what this page covers. This page is about the decisions behind a system that does not exist yet; if yours is already live, the first question is how much of it to touch. KGM SsangYong came to us as a live corporate site, and we reorganised its storage without touching the parts that worked. What we do with an inherited system is written up under software consulting.
We do, entirely; there is no office, and that is the working model rather than a gap in it. Architecture sessions happen on screen, so nobody on your side has to travel to get an answer. We come back to you within 2 business days.