Skip to content
UA.
TR

Open to new opportunities

Utku Altınay

Full-Stack Developer

I build multi-platform systems — one .NET API at the centre, native iOS, Android and React clients around it.

View projectsRésumé

SwiftUI · Kotlin · ReactC# .NET APIMySQL

Projects built

5

Languages used

4

Years writing code

5+

Months in enterprise IT

9

Currently

Management Information Systems at İstanbul Medipol Üniversitesi. Open to full-time roles and selective freelance work.

Based in

İstanbul, Türkiye

01 — About

Where I come from

I'm a full-stack developer based in İstanbul. I arrived here through two complementary routes: an Associate degree in Computer Programming at İstanbul Arel, and Management Information Systems at İstanbul Medipol. That mix is why I tend to start from the business process and work back to the architecture, instead of the other way around.

Most of what I build is multi-platform. A C# .NET API with a MySQL store sits in the middle, and Kotlin, Swift and React clients sit around it. Designing that boundary well — one contract, three very different consumers — is the part of the job I enjoy most.

I also automate the unglamorous parts. n8n workflows, NFC-driven review collection and WebAR menus all started as a small-business problem someone described to me in a single sentence.

02 — Skills

What I work with

Grouped by where each piece sits in the stack. Hover or focus any item to see what I actually built with it — a badge with no project behind it is decoration, not evidence.

  • Core — reach for it daily
  • Proficient — shipped production work with it
  • Familiar — used it, still growing

Backend

The contract every client depends on.

  • C# / .NETREST API serving three client platforms with JWT-based auth.
  • MySQLRelational schema design and query tuning behind the FitApp API.
  • PostgreSQLRow-level security and EF Core migrations behind the ArMenu API.
  • PythonScripting, data wrangling and glue code between services.
  • REST API DesignOne contract consumed by iOS, Android and web without branching.

Frontend

Typed, accessible interfaces that stay fast.

  • TypeScriptStrict mode, no `any` — the type layer is the documentation.
  • ReactComponent architecture for the FitApp web client and the Revio dashboard.
  • Next.jsApp Router, server components and static rendering on Vercel.
  • JavaScriptThe language underneath everything else on this list.
  • Tailwind CSSDesign tokens as CSS variables, dark mode without a second stylesheet.

Mobile

Native on both platforms, not a wrapper.

  • Swift & SwiftUIFitApp iOS client — MVVM, Swift Charts, async networking.
  • Kotlin & AndroidNative Android clients and a Firebase-backed request tracker.

Tooling & Automation

Shipping, and removing the work nobody wants to repeat.

  • GitBranch-per-feature, readable history, reviewable diffs.
  • DockerChiseled .NET images and a reproducible local stack for ArMenu.
  • n8nWorkflow automation for small-business operations.
  • SupabasePostgres, auth and storage when a project doesn't warrant its own API.
  • FirebaseRealtime data and auth for the BT Support Android client.
  • VercelPreview deployments and edge delivery for every web project here.

03 — Projects

Things I have built

Every one of these started as a problem somebody actually had. Each card opens into a case study: the architecture, and the decisions behind it.

The FitApp dashboard shown on the web, on iOS and on Android at the same time.
LiveFull-stackMay 2026 — Present

FitApp

One .NET API, three native clients, and the habits that keep someone coming back.

The problem
Fitness tracking data is only useful when it follows the person, not the device — and a tracker nobody opens after the second week is not useful at all. Building the same feature set three times, once per platform, would have meant three sources of truth and three sets of bugs; building only the tracking would have meant an app with nothing to come back for.
What I built
One C# .NET 8 API over MySQL as the single source of truth, with thin clients on top: SwiftUI on iOS, Kotlin on Android and Next.js on the web. Beyond logging meals, water, steps and workouts, the server runs what makes it a habit — a Gemini-backed coach, daily and friend quests, a gold balance with a shop, a leaderboard, and chat over SignalR. Auth, validation and every rule live in the API; the clients present state and collect input.
  • C#
  • Swift
  • Kotlin
  • TypeScript
  • .NET 8
  • SwiftUI
  • Next.js
  • EF Core
  • SignalR
  • MySQL
  • AWS
  • JWT
Read the case study
Live demo
The Revio landing page: 'Find out what your customer thinks before they leave the table'.
LiveSaaSJan 2025 — Present

Revio

Customer feedback from a tap on the counter — no app, no sign-up.

The problem
A café or a hairdresser finds out a visit went badly when the one-star review is already public. Asking at the counter rarely works either: the honest answer is the one people will not give to your face, and every alternative — find the listing, sign in, write something — loses almost everyone before the first tap.
What I built
A multi-tenant SaaS. Each business gets NFC cards for its counter and tables; the customer holds a phone to one, rates the visit in a few seconds and can leave a note, with nothing installed and no account created. Behind the tap is a .NET 8 API in a clean architecture — CQRS through MediatR, EF Core over MySQL, Redis on the hot path and Hangfire pulling Google Business Profile reviews in overnight — and a React dashboard where scores, notes and Google reviews meet, split by table, till and staff member.
  • C#
  • TypeScript
  • .NET 8
  • MediatR
  • EF Core
  • React
  • Tailwind CSS
  • MySQL
  • Redis
  • NFC / NDEF
  • Google Business Profile API
  • Hangfire
  • Docker
Read the case study
Live demo
The ArMenu owner dashboard beside the guest app showing a burger in 3D with an AR button.
LiveSaaSSep 2026 — Present

ArMenu

Multi-tenant QR menus with in-browser AR — and no app to install.

The problem
A printed menu cannot show a guest what a dish looks like, cannot be read in their language, and cannot be changed without a reprint. Every digital answer to that asks the guest to install something, which at a restaurant table is where the idea dies.
What I built
A multi-tenant B2B SaaS. A guest scans the QR code on the table, reads the menu in their own language, and places a dish on the table in augmented reality through model-viewer — in the browser they already have open. Behind it: a .NET 10 API over PostgreSQL, and a separate Node service that turns an uploaded 3D model into optimised GLB, USDZ and poster images.
  • C#
  • TypeScript
  • .NET 10
  • ASP.NET Core
  • EF Core
  • React 19
  • Tailwind CSS
  • PostgreSQL
  • S3 storage
  • WebAR
  • Docker
  • OpenTelemetry
Read the case study
Live demoSource
A character sheet and the pixel-art battle arena, side by side on two phones.
LiveFull-stackJun 2026 — Present

TTRPG Companion

A real-time table for a tabletop campaign — and a server nobody has to trust.

The problem
Running a tabletop campaign means tracking hit points, initiative order, inventory, status effects and relationships across paper sheets and a group chat. When part of the table is remote, all of that shared state lives in one person's head — and so does every dice roll, which everyone else simply has to believe.
What I built
A turn-based companion for the campaign I run with friends. One Expo client — iOS, Android and, through react-native-web, a plain browser link — talks to a .NET 8 API over a SignalR hub, so every player sees the same sheets, the same initiative order and the same combat turn as it happens. The rules live on the server: around forty domain services covering dice, combat phases, traits, status effects, triggered reactions, arena modifiers and a day-and-rest cycle.
  • TypeScript
  • C#
  • React Native
  • Expo
  • .NET 8
  • SignalR
  • EF Core
  • PostgreSQL
  • SQLite
  • Railway
Read the case study
Live demo

Also built

The entity-relationship diagram behind BT Support: users, requests, topics and messages.
ArchivedMobileSep 2024 — Dec 2024

BT Support

A request-tracking Android app for in-house IT teams.

The problem
During my internship I watched support requests arrive by phone call, chat message and corridor conversation. Nothing was tracked, so nothing could be prioritised.
What I built
A native Android app where employees file a request and IT staff see a single prioritised queue, backed by Firebase for realtime updates and auth.
  • Kotlin
  • Android SDK
  • Firebase
Read the case study
Source

04 — Experience

Work and study, in order

Two degrees and an enterprise IT floor, mostly overlapping. The analytical half and the engineering half arrived at the same time.

  1. Bachelor's Degree

    ·İstanbul Medipol Üniversitesi

    Sep 2023 — PresentManagement Information Systems

    Where the analytical half comes from: process modelling, data management and reading a business requirement before writing code for it.

  2. IT Support Intern

    ·İnnova Bilişim Çözümleri

    Sep 2022 — Jun 2023Internship · İstanbul, Türkiye

    Twelve months inside the IT operations of a large systems integrator — nine months long-term plus a three-month placement.

    • Handled first- and second-line support requests for internal users, reproducing issues before escalating them.
    • Worked day to day inside an enterprise ticketing and asset-tracking process — the direct reason I later built a request-tracking tool of my own.
    • Windows Server
    • Active Directory
    • Ticketing systems

  3. Associate Degree

    ·İstanbul Arel Üniversitesi

    Jan 2021 — Jan 2023Computer Programming

    The engineering foundation: algorithms, databases and object-oriented design.

05 — Contact

Let's talk

Open to full-time roles and to interesting freelance work. If you have a problem that needs an architecture rather than a page, I would like to hear about it.

Elsewhere

Based in

İstanbul, Türkiye

A direct email always reaches me. The form goes to the same inbox — use whichever you prefer.