Get a quote

System Architecture · Umraniye

System Architecture for Umraniye businesses

A business in Umraniye does not have to grow by adding to the building it already has; around Dudullu the second workshop opens in another block, sometimes under another name. In software that tends to turn into a second installation: another database, another login, another report. The architecture question in Umraniye sits exactly there. Is a new unit a new installation, or a definition written into one shared install? On Vipkurum we took the second answer, and seven institutions run that one system under their own brand.

System Architecture — Umraniye

Umraniye's fabric puts mechanical contracting, air conditioning service and small manufacturing door to door on the industrial estate. If growth goes sideways, the result is a second unit, a second name and a second set of books. The closest shape in our portfolio is Vipkurum. One thing has to be said about the fit: Vipkurum was written for education institutions, and the production side of manufacturing, a parts store or a field work order is not inside it. What we take is not the teaching but the setup decision, pulling functions that would otherwise scatter across separate programs into one data model and deciding where a unit's boundary runs. Laravel sits underneath; MySQL and MongoDB keep the records, Redis the cache, React the panels, React Native (Expo) the phone side.

  • Timetable, exam, student, guardian, payment and reporting do not break apart into separate programs but sit in one data model, so adding a function is not opening another program.
  • A teacher, a guardian and an administrator reach the same record only as far as their permission goes, and that limit is cut at the record layer rather than by hiding a menu.
  • Taking one more institution under the roof is a definition rather than an installation: it signs in at its own address, its records stop at that line, and the codebase never forks, so maintenance stays on one track.

Why Algoriel

  • The parts read one source

    At Tahlil.com the site, the admin panel and the mobile app read the same information instead of behaving as three systems.

  • Where each job is solved comes first

    Which layer handles which job is decided before code, because work that has to move later is expensive to move.

  • The summary recomputes itself

    As the Günlük Hava Durumu archive grows, the climate summary recomputes from it; nobody maintains a monthly table by hand.

  • One rule for file layout

    On the KGM SsangYong site, where a file is written and under what name now follows one rule the upload code obeys.

  • Where the data divides

    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.

  • What a record attaches to

    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.

  • Permission held in the data model

    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.

  • Splitting the read path

    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.

  • Interfaces on a single system

    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.

  • Storage laid out on day one

    The naming and folder scheme files will live under is fixed at the start; a layout imposed afterwards turns into a migration.

Work like this

System Architecture · Case study

Vipkurum — one data model instead of six programs, the unit boundary at the address

A multi-tenant school and institution platform. Work that usually scatters across separate programs sits in one data model: timetable, class, exam, student, guardian, payment and reporting. A teacher, a guardian and an administrator reach the same record only as far as their permission goes, cut at the record layer rather than on a screen. Announcements stay inside the institution, and invoices come off the administrator's own tenant data. Seven institutions run one system under their own domain and brand, and a neighbour's rows reach nobody else's panel. Laravel sits underneath, MySQL and MongoDB hold the records, Redis the cache.

Read the case study →

Working with Umraniye teams, remotely

We have no office, so work for this city runs remotely and we do not offer on-site support. What was done, and why it was done that way, stays in writing. The project pages mark which builds came out of a partnership.

  • The first release ships as a working piece; extras follow later.
  • Every client we know of is in Turkey.
  • Decisions stay in writing; progress shows in working screens.

Frequently asked

  • Why is a second installation for a second unit a problem?

    Two installations mean two maintenance tracks. On Vipkurum the codebase stayed single, so one correction reaches every institution at the same moment, releases never drift apart, and nobody has to ask which unit is running what.

  • Will the units' records not bleed into each other?

    The boundary sits at the record layer. An institution signs in at its own address, and its student, payment and invoice rows stop there rather than opening on a neighbouring panel.

  • We are a manufacturing workshop, not a school. What does Vipkurum say to us?

    Vipkurum was written for how schools and institutions run, and we say that plainly. What carries across is not the timetable but the fact that functions expected to scatter can hold in one model, and where the boundary is drawn. Production planning or a parts store is not what this project shows.

  • We are inside an industrial estate. Would you not need to see the work in person?

    We keep no office and offer no on-site support; we work fully remotely. The architecture decision comes out in writing: which functions gather into one model, where a unit's boundary runs, and which read belongs in the cache.

Let us settle where your data divides before any code is written.