Get a quote

System Architecture · Kartal

System Architecture for Kartal businesses

An accounting package and the working application sit open side by side on one desk; a keyboard carries the information between them. Kartal's fabric leans on the manufacturing strip along the E-5 and the area around the health campus. If a figure travels between two windows by keyboard, the architectural question underneath is narrow: which record does an invoice come off? In the CRM we built for a dental practice there is no second ledger. Invoices and reports are both readings of the patient record, so what was billed and what was done come off the same rows.

System Architecture — Kartal

If the work happens in one room, the record opens at a front desk and the figure is typed into another program after closing, the number of ledgers has already doubled. The work closest to Kartal's business profile is a CRM we built for a dental practice. Its reach stops somewhere, worth saying: a plant's production record, machine schedule or materials plan is not in it, and we have nothing there to show. What carries over is how many ledgers a system keeps. Treatment is planned tooth by tooth in ordered sessions, each booking attaches to one step of that plan, and invoice and report read the same patient record from different angles. Laravel runs the process, MySQL holds the records.

  • The invoice keeps no book of its own: the procedure already sits on the patient record, so what was billed and what was carried out are read in one place.
  • Reports come from the same patient record seen from another angle rather than a second store, with Laravel running the process and MySQL holding patient, plan and invoice rows.
  • Treatment is planned tooth by tooth in ordered sessions and every booking attaches to one step of that plan, so the invoice never has to ask elsewhere what was done.

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

Dental clinic CRM — invoice and report both read the patient record

A system built for a dental practice, with the number of ledgers cut to one. Treatment is planned tooth by tooth and split into ordered sessions spread over weeks. A booking is tied to when a given step of that plan happens, so changing the step moves the calendar with it. The invoice is not written somewhere else: the procedure sits on the patient record, so billing and treatment are read off the same rows. Reporting copies nothing into a second store either; it reads that record from another angle. Laravel runs the process and MySQL holds the records, letting a practice manager see where a patient stands on one screen.

Read the case study →

Working with Kartal 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

  • Our accounting package works. Do we have to replace it?

    No replacement is needed. What decides things is which record the invoice comes off. The procedure sits on the patient record, so the invoice comes off that, and the figure going to accounting is not retyped somewhere else. The hand-carry between two windows on one desk disappears.

  • Would you not build a separate warehouse for reporting?

    Not at this scale. A report reads the same patient record from another angle. A second store means a copy to keep in step, and an argument about which figure is right whenever it lags. Laravel runs the process and MySQL holds the records.

  • If the plan changes, do we have to correct the invoice by hand?

    No. The invoice reads the procedure that was carried out. When a step on the plan changes, what reaches the invoice is that step in its new form. With no line corrected by hand, nothing drifts out of agreement afterwards.

  • We run a workshop off the E-5, not a clinic. What does this evidence say to us?

    The system was written for a dental practice and we say so plainly; for a production record or a machine schedule we have nothing to show. What transfers is not the screens but the invoice being read off the job's own record. The same principle holds on a work order. We keep no office and have worked remotely from the start.

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