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

Mobile App · Istanbul

Mobile App for Istanbul businesses

Add a phone app to a group that runs several brands and the boundary question returns. The panel sits on a screen the institution owns; the app opens on a parent's or a student's own device, which the institution does not control. The quick answer is to hide a menu and filter the list on the handset. On Vipkurum we did not take that route: which institution the data belongs to is decided by the domain a login arrives from and by the record itself, not by the interface.

Get a quote Tell us about your project

Mobile App — Istanbul

Multi-brand groups, chains and dealer networks are dense in Istanbul, and in a structure like that a phone app ends up being the face of the whole roof rather than of one unit. The closest match we hold is Vipkurum. It was written for education institutions, so a retail chain or a dealer network is not something we can show. What carries over is where the line is drawn, not the sector. Seven institutions run one system under their own domains and brands, and each institution's student, guardian and payment records stay inside its own boundary. The mobile side is React Native (Expo), the panel React; both talk to the same Laravel back end, MySQL holds the data and Redis carries the read load.

  • The institution boundary, a tenant line in technical terms, sits in the record layer rather than on the handset: the app learns which institution it belongs to from the domain the login came through, and never filters a list itself.
  • One build carries the whole roof, so adding an institution means defining it in the system rather than compiling a separate version and putting a second listing in the store.
  • Announcements, messages and notifications travel inside the institution's own boundary, because the target comes from the institution's own boundary and not from a list somebody picked by hand.

Why Algoriel

  • The field team works from the phone

    A record opens where the work happens, so nobody drives back to the office to type it in again.

  • A screen instead of a brochure

    The SsangYong showroom kiosk runs on the shop's own device; a visitor never downloads an app, opens an account or hands over personal data.

  • A state change pings the phone

    When a Tahlil.com record changes state the notice reaches the phone, so nobody calls in to ask for a result.

  • One app, both stores

    Phone apps are written on a single framework, so there are never two native codebases to keep in step.

What we build

Mobile App

  • The platform follows the job

    An app bound for both stores is written from one source, so a fix reaches both in the same release. When an app leans on what only iOS offers, such as the Lock Screen, Face ID or the audio engine, we build it natively for iOS. Day Sheet and Nightproof were built that way.

  • An interface built for the moment of use

    The interface follows the moment rather than the device: standing up, one-handed, a few minutes at a time. On the KGM SsangYong showroom kiosk the touch targets, type size and navigation depth came out different from a phone app.

  • The services behind the app

    The server and the notification channel behind an app are decided alongside it, not after release. In Tahlil.com's patient app a push goes out the moment a physician signs off an interpretation, calling the patient back to the result.

  • Who made the entry, and where

    When it matters who made an entry and where, both are confirmed from the device itself. On the construction site attendance app the scanned code confirms the person, the device location confirms the site, and the two land in one entry.

  • Working with no connection

    If the work continues out of coverage, the app shows no waiting state; the information sits on the phone and reaches the back office in order once the signal returns. AlgoKlima's field app was built for exactly that condition.

  • Which device it lands on

    Distribution is a decision taken early rather than a final step: the crew's own phones, hardware the business buys, or a screen the store already owns. On the construction site attendance app the crew's own phones mean there is nothing to take down when a site closes.

Work like this

Mobile App · Case study

Vipkurum — the institution boundary sits at the domain, the mobile client carries no rule

Seven education institutions run the same system under their own domains and brands. An institution signs in at its own address, and its student, guardian, payment and invoice records stay within it. The line is drawn in the record layer, not the interface: the mobile client hides no menus and filters no rows on the device, it asks the same Laravel application and receives only its own rows. The mobile side is React Native (Expo) and the panel React; MySQL and MongoDB hold the records, Redis the cache. The limit, plainly: Vipkurum was written for education, and we have no multi-institution network in another sector to show.

Read the case study →

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

  • Do we have to publish a separate app for each brand in the group?

    No. On Vipkurum what decides the institution is not the build but the domain the login arrives from. One app carries the whole roof, so a new institution means one definition in the system rather than a second compile and a second store listing.

  • The app runs on someone's own phone. How is the record boundary held there?

    It is not held there — a boundary kept on a handset is not a boundary. The device only asks; the server decides which rows come back. A request for another institution's record returns nothing, whatever the app was told to send.

  • Can announcements and notifications cross between institutions?

    They do not. A notice travels inside the institution that raised it, and its target comes from that institution's own boundary rather than from a list somebody picked by hand. A misaddressed notification is stopped in the record layer, not on the screen.

  • Do you keep an office in Istanbul, and do you come to meetings?

    We keep no office and work fully remotely. How many cities the group opens in does not change the build either; what decides it is where one institution's boundary starts and ends, and we write that down in the first session.

Mobile App in other cities

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

Other services for this location

Tell us where your app will be used.

Get a quote or open the service