EN TR
Get a quote
View all services
Web software

One app carries the brochure pages and the request queue.

System architecture

The pieces and their boundaries are settled before code.

Enterprise & commercial software

Several institutions, one system, records kept apart.

Mobile app

One codebase, both stores: iOS and Android.

Software consulting

We take a running system over and improve it.

AI consulting

AI only where the problem actually calls for it.

Get a quote
EN TR

Software Consulting · Kartal

Software Consulting for Kartal businesses

When the system you inherit never pauses, you read it on moving ground. Kartal's fabric leans on the manufacturing strip along the E-5 and the area around the health campus. If your shifts run through the day there is no quiet hour, and the records keep growing while you look at them. Under that pressure the assumption that trips people up most is that money and service happen at the same moment. They do not: the sale lands on one day and the usage spreads over weeks. Pilatesco is where we drew that line.

Get a quote Tell us about your project

Software Consulting — Kartal

A commitment paid up front and a usage scattered across weeks are two ends of the same job. The work closest to Kartal's sector fabric is Pilatesco. Where it stops is clear: it was written for a sports and fitness business, and we have nothing to show for shift rosters or production planning on a manufacturing line. What carries is the shape of the record: the invoice is issued at the sale, the usage is read off the calendar, and both meet on one customer record. Laravel runs the process and MySQL holds packages, bookings and invoices; this installation has no Redis and no Inertia, and we name the stack as it is.

  • The first thing we separate in an inherited system is timing: if the invoice is issued at the sale, usage spreading over weeks is not an error but the correct shape of the record.
  • In Pilatesco a booking writes to the calendar and takes one session off the package; the balance sits on the customer record rather than in a separate ledger.
  • Cancellations, no-shows and completed sessions hit the balance differently, and which case returns the entitlement is written into the rule, not decided by whoever is at the desk.

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.

What we build

Software Consulting

  • 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

Pilatesco — the sale issues the invoice, the calendar carries the usage

How many people fit a slot is set by the instructor, the equipment and the hour together; a one-to-one session and a group class open under their own rules. The customer buys a package; writing a booking to the calendar takes one session off the balance, held on the customer record. Cancellations, no-shows and completed sessions hit that balance differently, and the rule says which is which. The invoice is raised at the sale while usage is read off a calendar spread over weeks; two timings meet on one record. Laravel runs the process, MySQL holds packages, bookings and invoices.

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 system runs around the clock, with no gap between shifts. How does a takeover work?

    Without stopping it. A takeover starts by working out at which moment each record is created, and that does not require the system to pause. We begin changes at the layer where the rule is written, because that is the only layer which moves without a release.

  • Why should the invoice and the usage sit on the same record?

    Because they do not happen at the same time. The money arrives on one day and the service spreads over weeks. Written into two programs, one ends up matched to the other by hand at month end. In Pilatesco the invoice is issued at the sale, usage is read off the calendar, and both are visible on one customer record.

  • Pilatesco is a studio business; ours is manufacturing.

    True, and it does not overlap. We have nothing to show for production planning, material requirements or shift rosters. What we describe is not a sector but how a record is built when the sale and the usage happen at different times.

  • Once you have taken a system over, who maintains it?

    We settle that in writing during the handover. We carry the upkeep of our own products, so maintenance cost is not something we describe from a distance. On a client system either we keep maintaining it or we leave it in a state your team can take on, and which of the two applies is agreed at the start.

Software Consulting in other cities

The other cities where we publish this service are below, grouped by province.

Other services for this location

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

Get a quote or open the service