Çekmeköy Municipality Central Software System
Explore the strategy, design, and development that power each project. From concept to launch, we deliver tailored digital solutions that solve real-world problems and drive measurable success.
Çekmeköy Municipality ran six separate citizen-facing applications, each with its own database holding its own copy of the same data. An announcement updated in one place stayed stale in another, and the same resident had to register again in every app.
GG Tech Teknoloji built a single central system behind all six: 63 modules and 80 entities on ASP.NET Core and MS SQL Server. Announcements, events, tenders, neighbourhoods, mukhtars and corporate content are now managed once and read by every application.
The migration ran on a separate server while the old system stayed live: the new system was brought up and verified, then during a one-hour window at night one was switched off and the other switched on. Citizen services never stopped.
Industry
Public Sector / Local Government
Service
Central system and integration architecture
Technology
ASP.NET Core, MS SQL Server, Next.js
Timeline
12 weeks
Industry
Public Sector / Local Government
Service
Central system and integration architecture
Technology
ASP.NET Core, MS SQL Server, Next.js
Timeline
12 weeks
One Identity, One Source: Six Applications on the Same Data
Two decisions carry the whole system.
One identity: a resident registers once and is recognised by the same account across all six applications. One-time SMS code verification, refresh tokens and failed-attempt lockout were solved once in the identity layer instead of being rewritten in every app.
One source: announcements, news, events, tenders, neighbourhoods, mukhtars and corporate content live in a single database. A change made in the admin panel reaches all six applications at once — no copying, no sync job, no question of which record is correct.
On the social assistance side the system also talks to SAYSİS; query records stay inside the institution and the integration is written as a gateway that can be switched off.
Key Features
- One admin layer, 63 modules: Announcements, news, events, tenders, projects, galleries, publications, polls, neighbourhoods, mukhtars, facilities, bus lines, the org chart and messages to the mayor — all from one panel under one permission model.
- Central citizen identity: Sign-in with a one-time SMS code, refresh tokens and failed-attempt lockout. A resident registers once and is recognised by the same account in all six applications.
- Events and ticketing: Venue seating layouts, session and price definitions, session rules and reservations; every ticket is tied to a citizen account.
- Loyalty card and turnstile access: The Çekmeköy Kart talks to facility turnstiles. Passage records are written idempotently and guarded by a row version, so a passage read twice still produces one record.
- SAYSİS integration for social assistance: A query gateway for Social Market and Social Service Center processes; query records stay inside the institution and the integration can be switched off from configuration.
- Three-environment release path: Development, test and production on separate servers. Each release is verified in test first; production goes live by handover rather than by stopping the running system.
Why There Was No Downtime
The zero-downtime result came from how the cutover was staged, not from a failover setting. The new system was never written over the production server: it was brought up in full on a separate machine, verified in the test environment, and held ready while the old system kept serving.
The handover happened in a one-hour window at night — the old system was switched off and the new one switched on. Because both systems were standing at the same time, the way back stayed open throughout. Downtime as experienced by residents: zero.
How We Solved the Problem
Client & Context
Client: Çekmeköy Municipality
Çekmeköy Municipality had six citizen-facing applications: the corporate website, the mobile app, event ticketing, Social Market, the Social Service Center and the Çekmeköy Kart loyalty card. Each carried its own database.
The Problem
The same data sat in six separate places. An announcement updated on the website could stay stale in the mobile app, and the same resident had to register again in every application. There was no single source that could say which record was correct, and adding a new service meant writing the same content management for a seventh time.
Solution & Mobile Features
We built one central system behind all six applications. Content, identity and transaction data live in a single database that every application reads from. The admin side was consolidated into one panel of 63 modules; the citizen side was connected to a shared identity layer. Each application kept its own interface — what became single was the source behind them.
Tech Stack & Architecture
Technologies:
Architecture: A layered build: domain model (Core), data access and external integrations (Infrastructure), HTTP surface (Api). Admin and citizen endpoints sit in separate controller families under separate permission models while sharing the same domain model. Schema changes travel as versioned database migrations — 66 of them across 12 weeks. Development, test and production run on separate servers.
Our Process
- 1
Scope mapping: the data and processes carried by each of the six applications were mapped and the shared parts separated out.
- 2
Domain model: a common content, identity and transaction model built across 80 entities.
- 3
Admin layer: 63 modules consolidated into one panel with role-based authorisation.
- 4
Citizen identity: shared sign-in with one-time codes, refresh tokens and attempt lockout.
- 5
Integrations: a SAYSİS gateway for social assistance, idempotent writes for turnstile passages.
- 6
Test environment: the new system brought up in full on a separate server and verified.
- 7
Handover: a one-hour window at night — old system off, new system on, no interruption.
Results
Six applications now read from one source, residents are recognised by a single account, and the migration finished without stopping service. Adding a new service is no longer a matter of writing another admin panel — it is a module on the system that already exists.