Get a quote

Software Consulting · Catalca

Software Consulting for Catalca businesses

Where two locations doing the same job run two separate installations of the same software, a price change updates one and misses the other; the brand matches but the screen does not. A takeover then begins by counting installations. That is how software consulting in Catalca opens: how many installations do you have, and how many should there be. In Vipkurum the answer was one installation, with seven institutions running it under their own domain and brand.

Software Consulting — Catalca

Catalca's fabric is food retail and rural commerce. If your counter stands in one place and a second location sits kilometres away, every update travels to each one separately. We do have a client here, Merkez Kasap, and this is the only district page where we can write that. The work closest to the multi-location question is Vipkurum. The gap is plain: the platform was built for education institutions, we have nothing to show for a butcher's own cutting and weighing work, and we have never written farming or livestock software. What carries across is this: several institutions use one system while each institution's data stays separate, so a record stays under the institution it belongs to. Underneath sits Laravel, with MySQL and MongoDB holding the records and Redis the cache; the panel is React, the mobile side React Native (Expo).

  • Each institution signs in from its own domain, and student, parent and payment records stay inside that tenant's boundary rather than opening to the one next door.
  • Adding a location becomes a tenant definition instead of a new installation, so updates land on one install and no version gap opens between points.
  • The limit is written down: cutting, weighing and food production tracking were never built in Vipkurum and we have nothing to show there.

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

Vipkurum — seven institutions sign in under their own domain, one installation

Seven education institutions run the same software under their own domain and brand. They are kept apart at domain level: each signs in from its own address, and student, parent and payment records stay inside that boundary. Timetable, class, branch, exam and payment records live in one data model, and a teacher, parent or administrator reaches it at the level their role allows. The Content Management layer lets an institution define its own assessment type, so a new criterion never waits on a code change. Panel in React, mobile in React Native (Expo), both on one Laravel install; MySQL and MongoDB hold records, Redis the cache.

Read the case study →

Working with Catalca 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 run three installations at three locations. Does merging them mean losing data?

    Merging is not writing one set of records over another. Each location becomes a tenant. In Vipkurum the boundary sits at the domain level, so a record stays with the tenant it belongs to and never opens to a neighbour. What stays separate is the data, and what becomes shared is the code.

  • Do you actually work with anyone in Catalca?

    Yes. Merkez Kasap's printed menu was replaced by a single page opened from a QR code. This is the one district page where we can say that; elsewhere we frame it as the work closest to that district's sector profile, because we have no client there.

  • Vipkurum is an education platform. We are in food retail.

    The sector does not travel; where the boundary is drawn does. A tenant can be a school or a shop, and the rule holds either way: the address makes it clear which side a record belongs to. The counter work itself is outside what we can show, and we write that down.

  • Would you not need to come to our main location and see the system?

    We keep no office and work fully remotely, and the Catalca work ran that way too. What an inherited system needs from us is read access to the repository and the database, not a meeting room.

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