Get a quote

Process Tracking · Basaksehir

Process Tracking for Basaksehir businesses

Two very different requests land on a mould shop's website. One asks for a price on tooling that does not exist yet. The other is about a tool already on a bench, now drifting out of tolerance. Pushed through a single contact form they queue in the same inbox, and whoever opens it first decides the order. Diotek settles that at the form rather than after it: two request types, two flows, one Laravel application behind both.

Process Tracking — Basaksehir

Basaksehir's texture is the Ikitelli estate: machine building and mould shops side by side. If your front desk runs from one seat, the same person fields a request for new tooling and a call about a machine that has stopped, and on a loud shop floor neither gets answered before the evening. The work closest to that sector profile in our portfolio is Diotek. It was written for air conditioning and ventilation; production planning and machine load scheduling are not things we have built. What we describe is narrower: which flow a request enters on the site, and how it reaches operations already separated. A Laravel core, MySQL records and a Redis cache sit underneath, with Inertia and Tailwind on the interface. We keep no office and the team works remotely.

  • A request for a quote and a call about equipment already running travel on separate flows, so neither has to be sorted back out of a shared inbox.
  • The request record and the promotional pages sit on one MySQL schema, so the same information is never kept a second time in an outside form service.
  • Inertia moves between pages in the browser while routing and form validation stay in Laravel, so a request never opens with a required field missing.

Why Algoriel

  • Keeps working offline

    The field app keeps recording with no connection, and the queue reaches the server in order once signal returns. That is how AlgoKlima runs.

  • Entry from QR and location

    Where no fixed terminal can be installed, entry and exit are logged from a QR code and a location reading, and entitlement is worked out from those readings.

  • Records land the same hour

    Jobs close in the field, so the office sees where each one stands without waiting for end of day.

  • Office and field read one source

    The office panel and the field app read the same information, so nobody keeps a spreadsheet alongside it.

  • What the record attaches to

    Rather than mapping a process in the abstract, we decide what a record hangs on. On the construction system a row belongs to a person and a site at once, and the two are never separated. In AlgoRandevu we are building a structure where a booking can attach to a person, a room or a piece of equipment.

  • The entry that stays open

    Instead of a live dashboard, one rule: a matched check-in and check-out produce the hours, and a check-in with no scan out stays open. Whatever is stuck shows up as that gap.

  • Who was where, on the record

    Because a single row carries both the person and the site, totals separate by site. When one worker spends the month across two sites, those hours never fall into the same bucket.

  • What is left when the figure is disputed

    Because payroll is derived from matched pairs, the number argued over at month end has a time- and location-stamped record behind it. There is no parallel calculation sheet to reconcile against; the dispute happens over the record itself.

  • Records taken beyond coverage

    In AlgoKlima's service flow the chain does not break where the network does. Once the connection returns the waiting entries are processed in the order they were created, and an edit made in the field and one made in the office merge into a single record through conflict resolution.

  • Process rules kept out of the code

    Rules like the length of a step and the gap between consecutive ones belong in a product setting, not in the code. The aim is that changing one does not mean shipping a release, and that is what we are building into AlgoRandevu right now.

Work like this

Process Tracking · Case study

Diotek — a survey booking and a service call on two flows, one Laravel app

Air conditioning and ventilation brings two kinds of request to a site: a survey booking before a sale, and a service call after an installation. A visitor can ask for a date for the space before choosing a unit, and that request reaches operations on its own flow instead of joining the service queue. A maintenance or fault request opens against the installed unit, so the record stays written down rather than living in a phone note. Promotional pages and request screens run in one Laravel application: Inertia handles page transitions, routing and validation stay in Laravel, and content shares a MySQL schema with the request.

Read the case study →

Working with Basaksehir 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 already have a contact form. What does splitting the flows change?

    The trouble with one form is not visibility, it is order. A buyer asking for a price and a workshop calling about a stopped machine land in the same box, and reading order decides which gets answered. On Diotek the two request types were separated at the start, and the fields asked for change with the type.

  • Could we hand the form to an outside service instead?

    You could, but then the record is created outside the site and never sits beside the content. On Diotek the request record and the promotional pages share one MySQL schema, so searching, listing and looking back need no second account anywhere else.

  • Diotek is air conditioning work. We machine moulds. What carries over?

    We say plainly what Diotek is: software written for air conditioning and ventilation. What carries is not the trade but the shape of the request — new work and a fix on existing equipment as separate flows inside one application. Production planning and machine load scheduling stay outside this scope.

  • Requests pile up at the start of a season. Does one site hold that?

    On Diotek the seasonal peak is handled on the same codebase, with a Redis cache taking the read load. We publish no figure for how many requests that covers, because nobody has measured one.

What stands behind your month-end figure today?