Get a quote

CMS · Catalca

CMS for Catalca businesses

Merkez Kasap is a butcher's shop in Catalca — the one district page where place and client are the same fact. Its menu came off paper and onto a single page, and the work was a content job: the menu is not a photograph of a board but content modelled section by section, breakfast among them, so the address a reader lands on says which part of the menu they are in.

CMS — Catalca

Catalca trades on food at the western edge of Istanbul — producers, butchers, bakers and small shops the owner runs in person. There is no IT queue behind a counter like that, so the measure of a content system here is not how many buttons the panel carries. It is who waits when something changes. On paper the shop waited: new text went to a printer, and old prices stayed in circulation until the run came back. Modelling the menu by section took that wait out. Each section is a record of its own and carries its own address, so a code in the window and a code at the counter open the same menu at different points. The person editing a price stands behind the counter, with no developer queue and no print cycle in between.

  • Sections are modelled one by one, each its own record with its own address, so a code printed for the window opens the menu there and that link travels on its own.
  • A price change leaves the printed code alone. The address it carries holds still and only the content behind it moves, which takes the print run off the shop.
  • No ordering, payment or stock layer was asked for, so the Laravel setup we usually reach for stayed out: the menu is one page written with Node.js and Vue 3, and section changes cost no further request.

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

Merkez Kasap in Catalca — a paper menu modelled section by section on one page

A butcher's shop in Catalca, and the smallest build in our portfolio. Nobody asked for a system that would grow — they asked for one menu page whose prices the shop can change itself. We modelled the menu section by section and gave every section its own address, so a code printed for one section opens the page there. The printed code never changes; the content behind it does, and that is where the authority to update moved, from the printer to the counter. With no ordering, payment or stock layer to carry, Node.js and Vue 3 were enough.

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

  • Do you have an office in Catalca, near Merkez Kasap?

    No. The client is there; we are not. We keep no office and work fully remotely — what we set up here was a content model, not equipment on a wall.

  • Who updates the prices and the menu afterwards?

    The shop does. What an editor can change is decided by the content model: with section, item and price as separate fields, an update is a text edit. Had the menu stayed one image, every correction would go back through design.

  • Do the printed QR codes have to be reprinted?

    No. The address a code carries stays fixed while the content behind it changes. Printing returns only if you add a section that needs its own code.

  • Do we need a heavy admin panel, and can ordering be added later?

    No ordering, payment or stock layer was wanted here, so the stack shrank to the size of the job. Ordering is a separate build: records, payment and stock come with it, and we scope those before giving a date.

Let's talk about who will manage your content.