Get a quote

Software Consulting · Fatih

Software Consulting for Fatih businesses

A booking system you inherit rarely comes with a window to shut it down. Fatih's fabric leans on hotels and guesthouses and on the wholesale food and hardware trade around Tahtakale. If your front desk opens early and closes late, the system keeps writing while you read it. Consulting here is not an architecture proposal. It answers one question: where does the length of an appointment live? If it is buried in the code, every rule change means another release. That is the first place we look.

Software Consulting — Fatih

If one book holds everything on the historic peninsula, the hotel desk, the counter behind the shop and the crew running a refit all share a page. The work closest to Fatih's business profile is AlgoRandevu, and we say plainly where it does not match. AlgoRandevu is not a client system we took over; it is our own product, and we are building it right now. Our takeover evidence sits elsewhere: on the SsangYong corporate side we improved a running system, tuned it and reorganised its storage layer, working on top of a jQuery inheritance. What AlgoRandevu carries is a design decision: the booking rule belongs to a product setting rather than to the sector. Laravel, MySQL, Redis and Inertia sit underneath.

  • On a takeover we locate the rule first: if appointment length lives in the code, every change needs a release; if it lives in a settings table, it does not.
  • In the structure we are building, a booking can attach to a person, a room or a piece of equipment, so the business picks its own resource and we write no separate flow per sector.
  • What we do not promise is written down too: AlgoRandevu is not a live client installation, it is our own product still under construction.

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

AlgoRandevu — the booking rule lives in a product setting, not in the sector

Our own product, still under construction, and not a client installation. Instead of burying how long a booking runs, what it attaches to and how bookings line up back to back, we leave all of it definable inside the product, so a rule change is not a code change. In the structure we are building, a booking can attach to a person, a room or a piece of equipment. We build it on the same Laravel and Inertia ground as AlgoKlima and AlgoCar; bookings live in MySQL and Redis runs as the cache layer. Improving an inherited system without shutting it down is separate work; the contribution here is deciding where the rule gets written.

Read the case study →

Working with Fatih 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 a booking system that works. Can it be improved without taking it offline?

    Usually yes, but the order matters. We find where the rule sits first: if duration and spacing are written into the code, every change is a release. Once the rule moves into a setting, it can change while the system stays open. On the SsangYong corporate side we ran that same kind of work: improving a running system and reorganising its storage layer.

  • Can you install AlgoRandevu for us today?

    No. AlgoRandevu is our own product and we are still building it, so there is no live client installation to hand over. What this page describes is not the product but the decision inside it: keeping the booking rule out of the sector.

  • Can a hotel desk and a shop counter run on the same software?

    They can, as long as what a booking attaches to stays a setting. At a desk the resource is a room; at a counter it is a person or a piece of equipment. Rather than shipping a version for each, the same structure lets you pick the resource. This is what we are building now.

  • Would you come to Fatih and look at our current system on site?

    We keep no office and work fully remotely. On a takeover what gets examined is the record, not the desk: together we write down which information sits in which table, and whether the rule went into code or into a setting.

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