My R&D work

Beyond mobile apps — the fields I work in

Alongside the apps I have published, I design AI-based products in a range of other fields. For each one I studied the problem and worked out the technical solution architecture. The point of this page is to show which technical fields I work in.

  • 7projects across different fields
  • 12technical topics
  • 65technologies I worked with
  • 2019my first R&D project
2019

The start: a TÜBİTAK earthquake early-warning project

A year after learning Python, I built an earthquake early-warning system running on Raspberry Pi and Arduino and entered it into the TÜBİTAK competition. The sensor circuit, the data readout and the alert flow all worked; the project stalled halfway because I could not give it enough time.

That is where I learned the things no textbook covers: getting software to talk to hardware, power management, sensor noise. In most of the work below I am still in the same place: turning raw data from a sensor or a camera into a meaningful result.

  • Python
  • Raspberry Pi
  • Arduino
  • Sensor circuits
  • GPIO

Topics I went deep on in this work

The seven projects sit in different fields, but they all share the same core: taking some kind of data (an image, a location, a sensor reading or a time series), processing it and returning a meaningful result to the user.

Computer visionImage classification, object and defect detection, taking measurements from an image.
On-device AIPutting the model on the phone instead of a server: LiteRT, Core ML, model quantization.
Transfer learningStarting from open datasets, then specializing the model with domain-specific data.
Time series forecastingPredicting crowding and demand from historical data.
Natural language and speechMultilingual text generation, text-to-speech and caching strategy.
Vector searchExtracting image embeddings and running similarity search.
Geospatial data and mapsGIS layers, proximity queries, offline map packaging.
Optimization algorithmsVehicle routing (VRP) and operations research approaches.
Offline-first architectureData, map and messaging flows that work with no internet connection.
IoT and sensor dataCollecting soil moisture and temperature data through circuits.
Data privacyProcessing and encrypting health data under KVKK and GDPR.
User-contributed dataCrowdsourced data collection, verification and moderation.

Studied in depth

Three projects whose technical architecture I worked out

With these three I went all the way down to the data flow, the model choice and the architecture.

TG

Agriculture & Livestock

TarımGöz

Plant disease diagnosis with a phone camera, and data-driven irrigation.

Smallholder farmers have limited access to experts, and decisions are usually made on guesswork. I designed a diagnostic tool that identifies disease from a photo of a leaf and works without an internet connection.

What it does

  • Diagnosis from the cameraIdentifying a disease or pest from a leaf photo and producing a recommendation.
  • Irrigation calculationWorking out when and how much to water from the weather forecast and soil moisture.
  • Herd monitoringEarly detection of illness in animals through video and sensors.

Technologies I worked with

  • Flutter (Dart)
  • CNN image classification
  • Transfer learning
  • LiteRT (TensorFlow Lite)
  • Core ML
  • Model quantization
  • On-device inference
  • Dataset labeling
  • Data augmentation
  • Weather and satellite data APIs
  • IoT soil moisture sensors
  • Offline operation

Technical approach

  1. DataA base model from an open dataset (PlantVillage, for example), then specialization with field images.
  2. ModelA classifier built with transfer learning, then quantized and reduced to LiteRT and Core ML formats.
  3. AppInference runs entirely on the phone; diagnosis works with no internet.
  4. FeedbackUser corrections turn into new labeled data.
The hard part

The real challenge is not the model architecture, it is the data. A model trained on open datasets shot under laboratory conditions falls apart on a shadowed, blurry photo taken in the field. The fix: build the base model on open data, specialize it step by step with domain-specific images, and let the model say “I am not sure” when it is not confident.

SG

Disaster & Earthquake

Sağlam

Preliminary building risk screening, an evacuation plan and a disaster mode that runs without internet.

In a disaster, connectivity is the first thing to go. So I worked on an architecture that keeps the data, the map and the model on the phone and runs even with no network.

What it does

  • Preliminary risk screeningProducing a clear indicator from the year of construction, the floor count and visible damage.
  • Crack detectionAn on-device model that marks cracks in a photo taken with the phone camera.
  • Offline evacuationFinding the nearest assembly point on an offline map.
  • Disaster modeSending a status signal to nearby devices even if the network is down.

Technologies I worked with

  • Flutter (Dart)
  • Offline-first architecture
  • On-device computer vision
  • Crack / defect detection
  • Image segmentation
  • MapLibre
  • PMTiles map packaging
  • OpenStreetMap data
  • GIS and geospatial queries
  • Bluetooth nearby-device communication
  • Local database and synchronization
  • Rule-based scoring

Technical approach

  1. MapOSM data for Turkey is packed into a single PMTiles file and rendered with no server involved.
  2. ModelCrack detection trained on concrete surface images, shrunk down to a size that runs on the device.
  3. Data flowDevice-centric: the cloud only syncs when a connection is available.
  4. CommunicationWith no network, broadcasting to nearby devices over Bluetooth.
The hard part

The requirement to work offline drives every decision: the map, the model and the data all have to live on the phone. That means a constant trade-off between app size and coverage — carrying the entire map of Turkey and keeping the download size reasonable cannot both happen at once.

GZ

Tourism

GeziZeka

A guide that recognizes a landmark from a photo and generates multilingual audio narration.

Recognizing a landmark from a photo and delivering its story as multilingual audio, plus crowd forecasting from historical data. Image matching, generative text and caching all work together here.

What it does

  • Visual recognitionTurning the landmark photo into an embedding vector and running a similarity search in the database.
  • Multilingual narrationGenerating the narration text, voicing it and keeping the result in cache.
  • Crowd forecastingHour-by-hour crowd prediction from historical data.
  • Personal itineraryA route suggestion based on interests and available time.

Technologies I worked with

  • Flutter (Dart)
  • Image embeddings
  • Vector similarity search
  • PostgreSQL + pgvector
  • Supabase
  • Time series forecasting
  • Multilingual text generation
  • Text-to-speech (TTS)
  • Generation caching
  • Offline cache
  • Map and location services
  • Recommendation system

Technical approach

  1. RecognitionStarting with off-the-shelf image recognition, then moving to my own landmark embedding dataset.
  2. SearchEmbedding vectors are stored in pgvector and matched with a nearest neighbour search.
  3. NarrationGenerated text and audio are stored in the database; the same landmark is never generated twice.
  4. ScopeThe first release is kept to 50–100 popular landmarks.
The hard part

Off-the-shelf recognition services cover local landmarks poorly, so you have to build your own embedding dataset. And caching here is not a performance detail, it is the centre of the architecture — regenerating the same landmark's narration for every single visitor is unsustainable in both latency and cost.

Other fields

Four other topics I worked on

I studied each one separately because they land in different technical areas: health data regulation, optimization algorithms, geospatial data and crowdsourced data collection.

İT

Health

İyiTakip

Measuring healing from photos for chronic wound and skin monitoring.

Measuring healing from photos of the same area taken at different times. The real technical challenge here is less the image analysis than processing health data in line with regulation.

What it does

  • Measurement from imagesMeasuring wound size and colour change over time.
  • Comparative trackingAligning and comparing images of the same area taken on different dates.
  • ReferralReferring the user to a specialist and generating a report once a set threshold is crossed.

Technologies I worked with

  • Image analysis
  • Colour and area measurement
  • Image alignment
  • Reference scale calibration
  • Rule-based risk scoring
  • KVKK and GDPR compliance
  • End-to-end encryption
  • Health data retention and deletion flows
  • Wearable device data
The hard part

For the measurement to be trustworthy, the photo has to be tied to a known scale: distance and lighting change with every shot. Without calibrating against a reference object, you cannot claim “the wound has shrunk”. The regulatory side is every bit as decisive.

RA

Transport & Logistics

RotaAkıl

Route optimization and demand forecasting for fleets.

This project sits in a different area from the others: classical optimization rather than AI. The vehicle routing problem (VRP), capacity constraints and time windows.

What it does

  • Route optimizationThe most efficient route given vehicle capacity and the delivery window.
  • Demand forecastingPredicting peak hours and busy areas from historical data.
  • Carbon calculationCalculating emissions from distance and vehicle type.

Technologies I worked with

  • Vehicle routing problem (VRP)
  • Operations research
  • Heuristic algorithms
  • Constraint-based optimization
  • Time series demand forecasting
  • Routing and distance matrix APIs
  • Real-time location tracking
  • Emission calculation model
The hard part

VRP is an NP-hard problem; as the number of vehicles and stops grows, an exact solution becomes practically impossible. The job is not to find the best solution, but to pick the heuristic that finds a good enough one in an acceptable amount of time.

YK

Trees & Green Spaces

YeşilKayıt

Photo-based inventory and health monitoring of urban trees.

A project where geospatial data meets image classification: identifying a tree from a photo, placing it on the map with its location and tracking how it changes over time.

What it does

  • Digital inventoryCreating a species and health record from a photo and a location.
  • Health monitoringDetecting signs of disease and dieback from images.
  • Carbon calculationEstimated carbon sequestration from species and trunk size.

Technologies I worked with

  • Tree species image classification
  • GIS and map layers
  • Geolocation verification
  • Change tracking over time
  • Carbon sequestration calculation model
  • Crowdsourced data collection
  • User contribution verification and moderation
The hard part

When citizens collect the data, any guarantee of accuracy disappears. Making sure the same tree is not recorded twice, verifying the location and filtering out wrong species take far more effort than model accuracy does.

MN

Marine Pollution

MaviNöbet

Marine pollution detection from photos and a geotagged reporting network.

Recognizing pollution and mucilage on the water surface from images and mapping it by location. A combination of image classification and geospatial density analysis.

What it does

  • Visual detectionIdentifying the type of pollution from coastal and sea photos.
  • Reporting networkCollecting and verifying geotagged reports.
  • Density mapProducing a pollution heat map over time.

Technologies I worked with

  • Water surface image classification
  • Satellite and drone imagery analysis
  • Geospatial clustering
  • Heat map generation
  • Spatio-temporal analysis
  • Open data integration
  • Report verification flow
The hard part

A water surface is a hard subject to classify: reflection, waves and light make the same pollution look completely different. A false positive here is not just an error, it means sending an official out for nothing.

Solo work

All of this work is mine: studying the problem, the technical research and working out the solution architecture — I ran every part of it on my own.

A note

This work is at the design and research stage — these are not shipped products. For the apps I have published, see the Apps page.

The point here is this: beyond mobile app development, I also work in fields like computer vision, running models on device, geospatial data and optimization. For each one I can explain what I chose, why I chose it and where the hard part sits.

Let's talk about these topics

I am happy to walk through the technical approach, the data strategy or the reasoning behind any decision in any of them.