Veli Kaan Çetinel

Identity space wars: when two systems disagree about what things are

Thu, 10 Sep 2026 00:00:00 GMT

Of everything that happened during the ARES zero-downtime migration, one discovery changed how I think about system boundaries — and it started with a sentence everyone believed:

"The v2 file id and the legacy reference number are basically the same thing."

The assumption

Running two schemas side by side means every entity exists twice: once in the decade-old legacy tables, once in the new normalized schema. To keep clients working during the transition, APIs accepted and returned identifiers — and the comfortable belief was that for files, the new files.id and the legacy reference (islem_ref) were interchangeable. Same records, same numbers, no translation needed.

It's the kind of assumption that feels safe precisely because everything seems to work. Most traffic hits recent records, recent records were created in both systems near-simultaneously, and near-simultaneous creation produces ids that are... close. Close enough to pass every casual test.

The measurement

Before building more on top of that belief, we did the boring thing: pulled 55 production files and compared their ids across both systems.

54 of the 55 differed.

Worse than differing — the two id ranges overlapped. A given number could be a perfectly valid file id in both systems, pointing at two different files. That's not an error you catch with a "not found" response. That's an API call that succeeds, returns a real file — the wrong one — and corrupts data downstream with complete confidence.

One overlap away from a claims adjuster editing someone else's damage file. We stopped everything id-related that day.

Two-front fix

Front one: unify the file id space

For files themselves, we ended the dual identity at the schema level: the legacy reference was adopted as the canonical v2 file id — one number, one meaning, in both worlds. That decision rippled through 13 file foreign keys and another 22 relation and audit FKs, but it removed the single most dangerous ambiguity: from then on, "file 84213" meant the same record no matter who said it.

Front two: the wire contract

Files were only the loudest case. Every reference vocabulary the APIs spoke — vehicle makes and models, provinces and districts, occupations, policy types, insurance branches, document types, campaigns, invoices, regions — had its own legacy id space, and clients had legacy ids baked into requests, caches and saved filters.

You can't flip all of that at once. So we ran an eight-phase wire contract program, one vocabulary family at a time:

Ship the v2 ids alongside the legacy ones.
Deploy dual-read mappers in every client — the React SPA, the Flutter tablet and the mobile app, simultaneously — so both id dialects are understood during the phase.
Flip the API surface to emit v2 ids as canonical.
Burn the legacy ids out of requests, then out of responses.

Some families were mechanical. Some — like insurance branches — needed live data remapping mid-phase. Each phase was small enough to verify and, critically, small enough to roll back.

What made it survivable

Dual-read, not dual-write, in the clients. Clients never chose which id to send; they only had to understand both while a phase was in flight. Choice stayed on the server, where it could be changed without an app-store release.
Auditability per phase. Each vocabulary flip had its own before/after checks — the same discipline as the table-family migrations, applied to identifiers.
Naming the enemy. Once we called the problem "identity spaces", conversations changed. "Which space is this id from?" became a standard review question — the cheapest bug-catching tool we added all year.

The takeaway

Every integration has identity spaces, and every long-lived migration will eventually put two of them in the same request. The failure mode isn't an exception — it's a successful call returning the wrong entity, which is as bad as data corruption gets while looking exactly like health.

So: never trust "they're basically the same number". Sample it. Measure it. Ours died on 55 files — and measuring cost an afternoon, while believing would have cost us production data.

Questions about migrations or API versioning? Reach out.

The Scenario Runner: an internal tool that became our migration's parity gate

Thu, 10 Sep 2026 00:00:00 GMT

While re-platforming ARES — the 50-module damage-management system I wrote about in the zero-downtime migration post — we kept hitting the same wall, over and over:

you can't test a damage file you can't create.

The problem: state is expensive

In a damage-management platform, nothing interesting happens on an empty database. A single meaningful test case is a deep object graph: a claim file with a vehicle, a customer, a policy with entitlements, assigned tasks in the right states, mandatory documents, expertise lines for parts and labor, maybe a spare-parts order halfway through its supply process.

Building that state by hand through the UI takes the better part of an hour — click by click, screen by screen. And whatever you build is subtly different from what your teammate built yesterday, so "it works on my file" became our version of "it works on my machine".

Unit tests don't fill this gap. We had hundreds of Pest test files for the pieces. But the bugs that hurt were between the pieces — a task state that blocks a document rule, an entitlement calculation that only breaks after a rejection-revision cycle. Those live in fully-formed files.

And we had a deadline-shaped reason to care: the migration. Every table family we flipped to the new schema needed the answer to one question — does a file behave the same in v2 as it did in v1? Answering that requires the same file, twice, in two systems.

What we built

The Scenario Runner is an internal admin tool that fabricates complete, end-to-end test files on demand:

Presets. A scenario is a named recipe: "insurance file with unsourced parts", "mini-repair file awaiting approval", "file ready for delivery". Pick one, click run, get a fully-formed file — with every entity in the graph created and wired.
A v1/v2 toggle. The same scenario can be materialized against the legacy path or the new one. That single switch is what turned a convenience tool into migration infrastructure.
Legacy Radar. Alongside the created file, the tool surfaces which legacy surfaces the scenario still touches — so "is this flow really v2-native yet?" stopped being a matter of opinion.

One design decision mattered more than the rest: scenarios are built through the same domain services production uses, not through raw inserts. A file fabricated by bypassing the business logic tells you nothing — worse, it can be a state the real system could never produce. Building through the front door keeps every generated file honest, and as a side effect it exercises the write paths themselves.

How it became the parity gate

Once the v1/v2 toggle existed, a workflow crystallized around it. Before a table family flipped to v2-primary, the same scenarios ran on both sides and the results were compared — statuses, computed amounts, timeline events, generated documents. Differences were either bugs to fix or intentional changes to document. Only when the scenario suite agreed did the flip proceed.

That's what I mean by parity gate: not a dashboard, not a meeting — a tool-enforced checkpoint that made "v2 behaves the same" a testable claim instead of a hopeful one.

It paid off beyond the migration, too. Bug reports now come with a scenario name instead of a fragile list of reproduction steps. New teammates explore the domain by generating files and poking at them. QA stopped hoarding hand-crafted test files like family heirlooms.

What I'd tell you if you're building one

Build through your domain services, not your tables. Fabricated state must be reachable state.
Make scenarios named and shareable. The value isn't creating a file — it's two people talking about the same file.
If you're migrating, make the target switchable. The moment a scenario can run against both systems, you have a parity instrument for free.
Surface what the scenario touched. Our Legacy Radar turned "are we done with the old system here?" into something you can see.

Internal tools rarely make it into portfolios or conference talks, but this one moved a 50-module migration more than most features did. If you're staring down a long strangler migration, build your scenario runner first — it's the instrument panel for everything that comes after.

Questions about migrations or internal tooling? Reach out.

94 seconds to 1.9: ditching information_schema for pg_catalog

Thu, 10 Sep 2026 00:00:00 GMT

During the ARES migration we built an internal tool called the Schema Dictionary: an explorer that maps every legacy table and column to its v2 counterpart. With two schemas totalling thousands of tables in flight, "where does this column live now?" was a question someone asked every day, and the tool was the answer.

There was just one problem: the page took 94 seconds to load.

The obvious suspects were innocent

The tool's data model was trivial — read the schema metadata, join it with our mapping annotations, render a tree. No business tables were touched at all. Yet it was the slowest page in the entire admin.

The culprit was the metadata read itself. Like most people, we'd written the introspection against information_schema — the SQL-standard views (information_schema.columns, .tables, .key_column_usage, and friends) that every tutorial reaches for. It's portable, it's readable, and on a schema this size it's brutally slow.

Why information_schema crawls

information_schema isn't a set of tables — it's a layer of views defined on top of PostgreSQL's real system catalogs. And those views do a lot of well-meaning work you didn't ask for:

Per-row privilege checks. The views filter to objects the current role can see, which means functions like pg_has_role() evaluated over and over — for every column of every table.
Standards-compliance joins. Mapping PostgreSQL's internal model onto the SQL standard's shape takes multi-way joins across pg_class, pg_attribute, pg_type, pg_namespace and more — repeated inside each view you touch.
Optimizer opacity. Query several of these views together (columns + constraints + foreign keys, as any schema explorer does) and the planner struggles to push conditions down through the view stack. Row estimates go sideways; nested loops bloom.

None of this matters when you look up one table. It matters enormously when a tool enumerates everything — twice, in our case, because we introspected both the legacy schema and the v2 schema to draw the mapping.

The fix: ask the catalogs directly

PostgreSQL's real metadata lives in pg_catalog — pg_class (relations), pg_attribute (columns), pg_constraint (keys and FKs), pg_namespace (schemas), pg_index, pg_type. Querying them directly skips the view layer entirely: no per-row privilege theater, no standards translation, and the planner sees plain tables with real statistics.

The rewrite was a day of work. A handful of queries shaped roughly like:

SELECT c.relname   AS table_name,
       a.attname   AS column_name,
       t.typname   AS data_type,
       a.attnotnull AS not_null
FROM pg_catalog.pg_attribute a
JOIN pg_catalog.pg_class c      ON c.oid = a.attrelid
JOIN pg_catalog.pg_namespace n  ON n.oid = c.relnamespace
JOIN pg_catalog.pg_type t       ON t.oid = a.atttypid
WHERE n.nspname = 'public'
  AND c.relkind = 'r'
  AND a.attnum > 0
  AND NOT a.attisdropped;

...plus the same treatment for constraints and foreign keys, and one pass to stitch results in application code instead of joining views against views in SQL.

Result: 94 seconds → 1.9 seconds. Same data, same page, same database. Fifty times faster by walking through a different door.

The honest trade-offs

Portability is gone. information_schema works on any SQL database; pg_catalog is PostgreSQL's own. For an internal tool pinned to PostgreSQL forever, that trade costs nothing.
Catalogs are internal API. They're remarkably stable (the queries above run unchanged from PG 11 to PG 18 — we know, because our legacy database was on 11), but they can change between major versions. Read the release notes when you upgrade.
You re-own privilege filtering. The views hid objects you couldn't access; raw catalogs show everything. For an admin-only tool that's fine — just don't forget it in user-facing contexts.

The takeaway

If a page that only reads metadata is slow, suspect the metadata layer itself. information_schema is a convenience view with real costs, and at "explore the whole schema" scale those costs dominate everything else. The catalogs underneath answer the same questions — just without the ceremony.

Questions about PostgreSQL internals or migration tooling? Reach out.

Re-platforming a 50-module Laravel monolith with zero downtime

Wed, 09 Sep 2026 00:00:00 GMT

For over a decade, ARES has been the system automotive damage operations run on. Workshops, experts, insurers and integrations all depend on it — every day, all day. Which is exactly what makes replacing it hard: there is no maintenance window. You can't tell an entire industry to pause while you migrate.

This is the story of how we re-platformed a 15,600-commit CodeIgniter-era monolith into a 50-module Laravel modular monolith on a completely new normalized PostgreSQL schema, without the legacy system ever going down.

The problem with the old schema

A schema that grows organically for ten years accumulates debt in ways code doesn't. Columns reused for different meanings. Duplicate sources of truth. Table families that made sense for the business of 2015 but fight the business of today. At some point, every new feature costs more because of the foundation it stands on.

The obvious answer — "rewrite it" — is also the classic trap. Big-bang rewrites of live enterprise systems fail so often it's a cliché. So we didn't do a big bang. We did a strangler migration whose dual-write changed direction mid-flight.

Act one: observer-driven dual-write

The core idea: the legacy system keeps running as-is, and every write to a legacy table is mirrored — through model observers — into the new normalized schema. The new schema stays continuously up to date without the legacy code ever knowing it exists.

This gave us three things:

Zero risk to production. If anything went wrong on the v2 side, the legacy system didn't care.
Real data from day one. The new schema was populated by real production traffic, not by a one-off backfill that goes stale.
A way to verify. We could compare both sides continuously and catch mapping mistakes while they were still cheap.

Identity resolution: the assumption that collapsed

The hardest part of running two schemas at once isn't writing to both — it's agreeing on what things are. Everyone assumed the new file id and the legacy reference number were "basically the same number". Then we sampled 55 production files: 54 of them differed, and the two id bands overlapped — a value could be a valid id in both spaces, pointing at different records. Silent data corruption waiting to happen.

The fix was an eight-phase wire contract program: every external API id space — vehicle taxonomy, provinces, policy types, branches, document types, campaigns, invoices — moved from legacy references to v2 ids, with dual-read mappers rolled out simultaneously across three clients (the React SPA, the Flutter tablet and the mobile app), so old and new payloads could coexist during each phase.

Strangling table families — a concrete one

With dual-write keeping the schemas in sync, we retired legacy table families one by one: rewrite every read path, rewrite every write path, keep the downstream feeds alive, then drop the tables.

The labor tables were the hardest, and took five phases: first the mini-repair flow, then the damage flows, then severing the pricing dependency, then an atomic migration of the entire labor-id space, and finally a reconcile command before the DROP. The post-DROP review still surfaced nine live error paths that only production traffic could find — each one hunted down the same week. Retire families, not tables; entities travel in groups.

Act two: reversing the mirror

This is the part most migration stories skip. Mirroring legacy writes into v2 keeps v2 fresh — but v2 is still the copy. The real milestone is the flip: read paths repointed to v2 in six waves, roughly 40 endpoints rewritten v2-native out of ~70 audited, and then the mirror itself reversed direction — v2 became the authoritative system, syncing back into the legacy tables for the consumers still reading them.

In August 2026 we removed the last legacy→v2 mirror leg and deleted the feature flags. The decade-old system is still queryable — but today it's the replica, not the source.

The supporting cast

A migration like this leans on infrastructure choices that don't show up in demos:

A transactional outbox with idempotency, so events published to the parts-supply platform never drift from what was committed.
HMAC-signed messaging for service-to-service calls and third-party webhooks.
Configurable workflow and document rule engines, so damage processes are data instead of hardcoded logic.
Internal tooling: a Scenario Runner that fabricates end-to-end test files on demand, and a Schema Dictionary that maps v1↔v2 tables — whose introspection dropped from 94 seconds to 1.9 the day we swapped information_schema for pg_catalog.

Across the program: 347 migration files, 236 test files, 533 merged MRs, 18 production releases.

What I'd tell you if you're facing the same thing

Dual-write via observers is boring, unglamorous — and exactly why it works. The legacy system never has to know.
Spend your design budget on identity resolution, and measure your assumptions. Ours died on a sample of 55 files.
Strangle table families, not tables — and budget for the post-DROP hunt; production always knows one more read path than you do.
The migration isn't done when the new system is up to date. It's done when the old one becomes the copy — plan the mirror reversal from day one.

This is a condensed version of the story — if you want to talk migrations, reach out.

Agentic MD – Markdown Reader for macOS

Mon, 31 Aug 2026 00:00:00 GMT

Agentic MD is a modern Markdown reader and workspace built specifically for macOS, power users and AI workflows — my own product, designed, built and shipped end-to-end.

Technologies: Electron, React, TypeScript, Model Context Protocol (MCP)

Key features

Native MCP bridge: connects with Claude Desktop, Codex and Cursor via stdio, so your AI assistant can read documents, edit markdown content and resolve comments in real time.
Element-level commenting: hover over any table, code block, Mermaid diagram or KaTeX formula and attach rich annotations with tags like #Review, #Fix, #Todo.
Rich rendering: full GitHub Flavored Markdown, Mermaid.js flowcharts and sequence diagrams, LaTeX / KaTeX math notation.
Instant path caching with live file-system watchers that sync external edits automatically.
Fast search: in-document highlighting and global search across all documents and headings.

Kaneo – GitLab-Driven Task Board

Sat, 15 Aug 2026 00:00:00 GMT

Kaneo is the company fork of an open-source project management tool (Hono API, React/Vite, PostgreSQL, WebSocket, MCP), organizing work in a three-layer request-pool → product → repo board structure.

Technologies: TypeScript monorepo, Hono, React, Drizzle ORM, PostgreSQL, WebSocket

In August 2026 I extended it to fit the team's actual workflow (23 commits, +26k lines).

Highlights

GitLab integration: branch and MR events advance tasks through board columns automatically — the board reflects reality without anyone dragging cards.
Task relations: when a blocker merges, dependent tasks are released automatically; umbrella tasks can spawn sub-tasks in other projects.
Cross-project views: an "All Tasks" screen, project grouping, "unassigned" and "just me" quick filters.
Personal GP: an F1-themed contribution leaderboard with selectable cars — because internal tools deserve fun too.

Garantili Oto Servis – Parts Supply Platform

Wed, 15 Apr 2026 00:00:00 GMT

GOS (Garantili Oto Servis) is the spare-parts supply platform of the damage ecosystem: parts from insurance claim files flow in, a robot price-query runs, experts review, offers are made and orders are placed against the Delta ERP (MSSQL).

Technologies: Laravel 12, PHP 8.4, PostgreSQL, RabbitMQ, Spatie Webhook Client, Angular, Apollo GraphQL

In spring 2026 I built the ARES↔GOS integration line on both sides — 119 commits on the API, 74 on the web panel.

Highlights

Reliable event delivery: ARES-side transactional outbox with idempotency, GOS-side webhook processing over RabbitMQ with signature verification — no lost or duplicated events between two Laravel systems.
The "unsourced part" process: a per-line state machine covering the expert-office queue, assembly-type webhooks, offer responses and per-part cancellations.
Pricing & orders: DB-driven supplier discount tables with brand-based insurance discounts, order placement for ARES files, Delta ERP status polling behind a cache-layered pull proxy, HMAC unified service identity.
Angular panel: the expert-office queue screen (card per line with robot snapshots), order tracking, inline offer price editing and responsive table layouts.

Destech Hasar – Destech Drive

Wed, 01 Apr 2026 00:00:00 GMT

Destech Drive is where dealers and branches live inside the ARES ecosystem: they track their repair files, upload photos and documents, follow statuses and message the operation center. The app consumes both the legacy ARES API and ARES V2.

Technologies: Flutter, Provider MVVM, GetIt/Injectable, shadcn_ui, Firebase Remote Config, Codemagic + GitLab CI

I'm the app's main developer in 2026 (86 of 125 commits) and ran its modernization as a planned five-phase program — each phase with its own plan, research, implementation and verification documents.

Highlights

Re-foundation: shadcn_ui design system with a theme service, router-based navigation with a tab shell (drawer removed), dark theme by default.
Single login + Remote Config: removed the dealer/branch selection step — v2-first auth with legacy fallback, refresh-token sessions, credentials in secure storage, and environment URLs served from Firebase Remote Config so they can change without a release.
Document upload/viewing redesign, Android 13+ media permissions, migration to the Android Photo Picker.
CI: GitLab pipeline building release-candidate and production Android artifacts from tags, plus GitBook user guides (EN/TR).

Destech Hasar – Ototek

Sun, 01 Mar 2026 00:00:00 GMT

Ototek is the tablet of the ARES damage-management ecosystem: every repair type gathered into a single Flutter application, with three mini-apps sharing one codebase — RSS (insurance damage expertise), RSA (workshop management for technicians and chiefs) and ROEA (vehicle inspection). Five languages (TR/EN/DE/AR/CS) with full Arabic RTL support.

Technologies: Flutter, Riverpod/Provider, auto_route, gRPC + REST, Sentry, Firebase Remote Config, OneSignal, Codemagic CI

Since February 2026 I've been the senior mobile developer — and because I also wrote the backend of many of these features in ARES V2, I own them end-to-end from API design to the tablet screen. 291 commits, 60 test files.

Highlights

Shared ChatSection: collapsed two separate messaging screens (RSS file notes, RSA work-order chat) into one shared component behind a repository contract — @mentions, photo attachments and voice notes with hold-to-record, slide-to-cancel, slide-up-to-lock UX.
Mini-repair flow end-to-end for the damage consultant role: work order form, expertise, approve/reject/revise cycle, entitlement indicator — with a performance pass (prefetch + parallel + dedup, single batch mutation).
Spare-parts module (SYPS): approval/decision flows, multi-team role switcher, ERP status badges, timeline.
Workshop (RSA): Gantt-style job scheduling, mandatory before/after photos, chief photo gallery, work-order messaging.
Mandatory-document checklists, an OOM crash fix in photo rendering, Arabic l10n + RTL, and Android/iOS build-chain maintenance.

ARES V2 – Automotive Damage & Repair Platform

Sun, 01 Feb 2026 00:00:00 GMT

ARES V2 is the re-platforming of the automotive damage management system Turkey's insurance repair operations run on: claim files, work orders, expertise (parts/labor/paint), document management, task chains, payments and dealer/expert/insurer administration. The legacy system — a decade-old CodeIgniter 3 monolith with 15,600 commits — stayed fully live during the entire migration, with zero downtime.

Technologies: Laravel 12, PHP 8.2, PostgreSQL 18 (CloudNativePG), Octane/FrankenPHP, Livewire, React 19, RabbitMQ, Redis, Kubernetes/ArgoCD

I joined as an API developer in February 2026 and became the technical owner of the legacy→v2 migration program in June: architecture decisions, schema design, releases and deploys, production incident response, code review and documentation.

What I built

The dual-write arc: legacy writes were first mirrored into the v2 schema through model observers — then table families were flipped to v2-primary, the mirror direction was reversed (v2 became authoritative, syncing back to v1), and in August 2026 the last v1→v2 mirror leg was removed. v2 is now the single system of record.
Identity resolution & the wire contract: files.id and the legacy reference turned out to be entirely different id spaces (54 of 55 sampled files differed). The fix was an 8-phase wire-contract program moving every external API id space to v2 — with dual-read mappers rolled out simultaneously across three clients (React SPA, Flutter tablet, mobile).
Strangler-pattern table retirement: the legacy labor table family was retired in 5 phases — including an atomic labor-id space migration and a post-DROP review that hunted down 9 live error surfaces.
Integrations: transactional outbox with idempotency for the parts-supply platform (GOS), HMAC-signed service-to-service auth, Delta ERP status proxy, configurable workflow and document rule engines.
Internal tooling: a Scenario Runner that generates end-to-end test files, and a Schema Dictionary (v1↔v2 mapping explorer) whose introspection I took from 94s to 1.9s by moving from information_schema to pg_catalog.
Product-tour infrastructure: screen/tour/step/chain model with anchor-based targeting, role & team audiences and media steps — powering a no-code tour builder for the product team.
Production operations: blue/green prod cutover, same-day incident-to-release cycles, 18 production release tags.

Measured outcomes

50-module modular monolith serving web admin, React SPA, tablet and third-party integrations
1,286 commits · 533 MRs merged · 347 migration files · 236 test files (Pest 4) · 97 docs
Schema introspection: 94s → 1.9s; legacy labor tables fully retired; last mirror leg removed

Orbina AI – Customer & Admin Dashboards

Tue, 01 Apr 2025 00:00:00 GMT

Orbina AI provides AI chatbot solutions for businesses — the very chat assistant on this site runs on it. As a freelance engineer working with a fully remote team, I built two of their products end-to-end.

Technologies: React, Next.js, Socket.IO

What I built

The Customer Dashboard: a responsive analytics dashboard for behavioral insights and chatbot management, with lead collection flows wired to the chatbot funnel.
The Admin Dashboard used to manage the platform itself.
Real-time updates with Socket.IO and third-party API integrations.
Modular React components with optimized rendering, delivered production-ready under tight deadlines.

Otokonfor – Otokonfor Workplace

Mon, 01 Jan 2024 00:00:00 GMT

</div>

Two mobile apps of various services for cars. One app is for customers and other one is for service provider.

Technologies: Flutter, Laravel

I was in the development of two applications for customer and service use. Employed REST API for backend infrastructure and seamless app performance.

Tur Assist – TurApp

Thu, 01 Jun 2023 00:00:00 GMT

TurApp is the Flutter app that Tur Assist — Turkey's largest roadside assistance and towing network — puts in the hands of its field personnel and partner companies: pending assignments, active services, arrival tracking, replacement vehicles, residential services, vehicle load inspection, shift management and video calls.

Technologies: Flutter, GraphQL (queries/mutations/subscriptions with generated schema), Provider + get_it/injectable, OneSignal, Firebase, flutter_background_geolocation, Yandex MapKit, biometric auth

I was the main developer from January 2023 to December 2024 — 1,682 of the repo's 3,400 commits (49%) are mine, taking the product from a near-empty codebase to the App Store and Google Play.

Highlights

Live job pool over GraphQL subscriptions — including the assignment logic: when a company rejects a job, the pool clears and the next company is assigned.
Background location worker: battery-aware tracking with isolate workers, feeding real-time arrival estimates.
Push migration in production: moved the notification stack from Firebase Messaging to OneSignal without disrupting live operations.
Biometric login, in-app product tours, admin panel views, video calling, a lite mode for low-end devices.

Mevbank - Lebib Yalkın

Sat, 21 Jan 2023 00:00:00 GMT

</div>

MevBank is a comprehensive legal database developed by Lebib Yalkın with over 70 years of expertise. It allows users to instantly access up-to-date laws, decrees, regulations, and amendments in Turkish legislation. Designed for legal professionals, it ensures fast, reliable, and accurate access to current legal content.

Technologies: Flutter, Laravel, GraphQL

Independently developed the mobile application, designing the foundational template. Gained insights into the legal industry and subscription-based payment systems.

Catchpad - Catchpad

Sat, 21 Jan 2023 00:00:00 GMT

</div>

This app allows its users to experience sport/education/health activities integrated with a mechanical disk pad. Pad has various sensors that calculates distance/acceleration/balance and these are used for related activities in the app. App controls pad via BLE communication.

Technologies: Flutter, Firebase, JavaScript

Solely developed the mobile app, managed the website, and initiated backend development. Transitioned to Firebase Firestore for resource-efficient development in a startup environment.

TaksiMaxi - TaksidePos

Sat, 21 Jan 2023 00:00:00 GMT

</div>

TaksiMaxi is a dual mobile application platform developed for TaksidePos, offering seamless taxi booking for passengers and real-time ride management for drivers. Inspired by BiTaksi, it was designed to connect riders with nearby taxi drivers quickly and securely. I was solely responsible for the app’s design and development; although fully functional, the project was shelved due to internal strategic changes.

Technologies: Flutter, Laravel, REST API, Socket.IO

Independently developed and designed the core structure of the mobile app. Contributed to the service industry with innovative solutions.

Sembol Nakliyat - Sembol

Sat, 21 Jan 2023 00:00:00 GMT

</div>

Sembol Nakliyat’s warehouse occupancy management app provides real-time tracking of storage usage across multiple locations. It helps optimize space utilization, monitor capacity status, and streamline daily logistics operations. I developed the app to improve operational efficiency and provide better control over warehouse activities.

Technologies: Flutter, Laravel, REST API

Revitalized the mobile app by collaborating with a team of three developers. Acquired operational knowledge in the transportation industry.