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

CMS · Kadikoy

CMS for Kadikoy businesses

Text can be written in the gap between two appointments. A photograph cannot: the room has to empty, the counter has to clear, and the light has to be right. If you run a clinic, a studio or a small shop in Kadikoy by appointment, that is where a content system stalls: hold the page until both are ready and nothing ships. Secretum, the product we are building right now, runs text and image down two separate production paths.

Get a quote Tell us about your project

CMS — Kadikoy

Most work in Kadikoy turns around a booking diary, and the person who greets a customer can be the person who updates the site. Words reach a page easily; pictures do not, because a shoot waits for the room. Secretum is an AI character platform, not a service business site — for bookings, patient records or a product catalogue we have nothing there to show. What carries across is not the record but the shape of production: one path makes the text, another makes the image. The stack is Node.js, Vue 3 and Laravel; MongoDB holds the record, a Redis queue carries the image job, the file lands on S3. Anthropic API writes the text; Flux API and Replicate render the picture.

  • Words and pictures are not tied to a single moment of publishing: the text settles as it is written, while the image job waits its turn in a Redis queue.
  • A rendered image is written to S3 once, so reopening the same card costs no second render and no second wait.
  • One Reverb broadcast from Laravel is read by both the Vue 3 interface and the React Native (Expo) client, so updates never need a second route.

Why Algoriel

  • Print becomes editable

    Çatalca Merkez Kasap moved a printed menu to a QR page, so a price change is an edit rather than a reprint.

  • Content gets an address

    Each menu section carries its own address, so a customer can link straight to the section they came for.

  • The institution authors

    Teachers on Vipkurum write their own lessons, tests and exams, so publishing does not wait on a developer.

  • Fixed code, editable page

    QRVizit fixes the printed address once; the page behind it stays editable. We are still building it.

What we build

CMS

  • Content modelling

    Which content types exist, and which fields each one carries, follows your own publishing work. At Vipkurum the assessment type is not hard-coded, so European and Turkish standards sit side by side on the same foundation.

  • The editorial interface

    The person writing and the visitor reading see the same information, with no second copy waiting to be synchronised. Keeping the admin panel and the published side in one application means the content is not held in two places.

  • Addresses and links

    Every page and every section carries a permanent address of its own, so a shared link always opens the same place. At Çatalca Merkez Kasap the menu is split into sections, and codes on different tables land on different points of the same page.

  • Access and permissions

    Who sees what, and who may change it, is defined together with the content type. At Vipkurum a teacher, a student, a parent and an administrator read the same lesson programme at their own level of permission.

  • An update is not a reprint

    When a price, a phone number or an address changes, the printed material stays as it is and the page is updated instead. Çatalca Merkez Kasap keeps its menu as text, so a price change never reaches the printer.

  • Repeat reads

    When the same page is opened again and again, it is served from a ready copy rather than rebuilt each time. QRVizit, still under development, opens a repeatedly scanned card that way.

Work like this

CMS · Case study

Secretum — text and image on two production paths, the image job queues

Our own product, under construction right now, not a client handover. A user builds an AI character and the character posts into a feed. The split on the content side is this: Anthropic API writes the text and it goes straight into the feed, while Flux API and Replicate render the image and that job joins a Redis queue. The file is written to S3 once and never rendered again in the feed. The character's identity and accumulated history sit in MongoDB as a durable record tied to the account. The limit is plain: a social feed prototype, not booking or catalogue management.

Read the case study →

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

  • Can a page go live before its photograph exists?

    Yes, and that is what the split is for. The text moves on its own path and settles the moment it is written. The image job joins a queue and lands in its own record when it is done. The page never has to wait at the speed of its slowest part.

  • We work by appointment in Kadikoy. Do you send a team to take the pictures?

    No, and we keep no office there either; we work fully remotely and give no on-site support. Photography is not work we take on. What we build is the production path that stops a page waiting on an image, whoever made it.

  • Is Secretum a released product?

    No. We are building it right now, so we describe it as a mechanism under construction rather than a finished reference: text and image travel two routes, the image job waits its turn in a Redis queue, and the file is written to S3 once.

  • Does a model have to generate the image?

    No. The mechanism does not depend on who produces the picture, only on the job being queued. An upload behaves the same way as a rendered frame, and the page waits for both in the same place.

CMS in other cities

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

Other services for this location

Let's talk about who will manage your content.

Get a quote or open the service