Get a quote

Software Consulting · Pendik

Software Consulting for Pendik businesses

Taking over a system mid-job is nothing like starting on an empty desk. Pendik's fabric leans on manufacturing SMEs and multi-site service organisations. If your work stretches across weeks, then on the day it is taken over some of it is already half-done. If the old system holds the appointment but not the sequence behind it, that sequence is sitting in somebody's head. The first job in consulting is moving it from a head into a record. The dental clinic CRM is where we solved exactly that.

Software Consulting — Pendik

When multi-step work is inherited, the difficulty is continuity, not the code: which step is this customer on, and what comes next? The work closest to this district's business profile is the dental clinic CRM. Where it does not reach is stated plainly: it was written for a health clinic, and we have nothing to show for a production step in a manufacturing SME or a route plan for a service organisation. What carries is that the plan is itself a record — treatment stands on its own, independent of any appointment, and each appointment attaches to a specific step, so a changed step shifts the calendar with it. Laravel runs the process; MySQL holds patients, plans and invoices.

  • We look at where the inherited system keeps the sequence: if the calendar only shows an hour, the step a job has reached lives in someone's head rather than in a record.
  • In the dental clinic CRM the plan holds which procedure goes to which tooth, split into ordered sessions; an appointment attaches to one of those steps, and changing the plan shifts the calendar.
  • The invoice keeps no ledger of its own — because the procedure sits on the patient record, what was billed and what was carried out are read from the same place.

Why Algoriel

  • We read the code first

    We did not build the KGM SsangYong corporate site; we read the inherited codebase and left the parts that worked untouched.

  • Fix where the load sits

    The same catalogue query hit MySQL on every page open; that read moved to a Redis cache and nothing else was disturbed.

  • We stay inside your framework

    On the KGM SsangYong site the inherited Laravel, Tailwind and jQuery set was kept; the cache layer was the one addition to the stack.

  • We reconnect broken chains

    At Resterm the calculation sat in a sheet, the catalogue in a file, the quote somewhere third; selection now runs to cart, project, and customer.

  • Reading the code first

    We read the inherited codebase through, then name what moves and what stays untouched, one item at a time. The scope of the change comes out of that reading rather than a template.

  • Staying on the existing framework

    A library the maintaining team has never worked with would be a cost we left behind on our way out. KGM SsangYong's corporate site arrived with its framework and front-end libraries already chosen, and not one dependency was added to that set.

  • The limit of the change

    Only the slow places get opened; heavy spots are handled one at a time and the rest stays where it is. Where that limit falls is written down for you once the reading is done.

  • Tidying the file layout

    Scattered files move into a single naming and folder scheme. Which model uses which file becomes visible without reading code.

  • Taking weight off the reads

    The same query repeated for every visitor can be run once and shared from there. On KGM SsangYong's catalogue pages that query no longer runs until the data changes.

  • The decision taken before code

    Some decisions are made before the first line and are expensive to correct later. Resterm's software was built on the manufacturer's own product structure, because it was clear from the start that a general-purpose quoting tool would not carry it.

Work like this

Software Consulting · Case study

Dental clinic CRM — the plan carries the sequence, each appointment binds to a step

A treatment plan is built tooth by tooth and split into ordered sessions spread over weeks; the treatment is a record in its own right, independent of any appointment. Each appointment attaches to a specific step, so when a step changes or a session is added the calendar moves with it and no appointment is left dangling. The invoice keeps no separate ledger: the procedure sits on the patient record, so what was billed and what was carried out are read from one place. Laravel runs the process, MySQL holds patients, plans and invoices. Written for a clinic; production steps and service routes fall outside it.

Read the case study →

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

  • We have jobs half finished. What happens to them during a takeover?

    They are not reset. The plan record is built first, then work in progress is placed onto it at the step it actually reached. In the dental clinic CRM the treatment is a record independent of the appointment, which is what makes that placement possible without disturbing the calendar.

  • Our calendar works. Why would we need a plan?

    A calendar shows an hour, not a commitment. When work runs across weeks the calendar never says what the next step is, and that usually lives in someone's head. Once the plan is a record, the appointment attaches to it, and a changed step shifts the calendar too.

  • How do you explain dental software to a manufacturer?

    We do not explain the sector, we explain the shape of the record. A plan is built from ordered steps, an appointment binds to one step, the invoice is read off the same record. Rename the step from a tooth to a machine or a service point and the chain holds. For production planning we have nothing to show.

  • We are a multi-site service organisation. Does each site work separately?

    The plan record belongs to the job, not to the site. The same job can continue at a different site because the sequence sits on the plan rather than on the calendar. We do no on-site work; everything runs remotely, handovers included.

Would you like us to read the system you already have?