Tanja Duro
GitHub LinkedIn

Software engineer · Berlin

I build reliable software around applied AI.

My work sits between backend engineering, automation, and product delivery: turning a useful idea into a system that can be tested, operated, and improved.

See selected work Email me

Selected public work

Evidence, not a project gallery.

Two public repositories that show how I frame a practical problem and carry it through implementation, testing, and delivery.

Market Lister

Go · Gemini API

A command-line tool that turns folders of product photos into editable marketplace listing drafts for Vinted and Kleinanzeigen.

Problem
Creating accurate bilingual listings from phone photos is repetitive, and visual details such as labels, sizes, and flaws are easy to miss.
My contribution
I designed and implemented the Go workflow: image input, structured Gemini output, validation, optional grounded enrichment, and Markdown rendering.
Public evidence
The repository includes the working CLI, focused tests, CI, a tagged release, documented failure handling, and explicit limits. Generated copy remains a draft for human review.
Read the repository

MLOps Quickstart

Python · FastAPI

A deliberately small reference service for taking a scikit-learn model beyond a notebook and exposing it through a tested HTTP API.

Problem
Model experiments often omit the basic service boundaries needed for repeatable inference and operational checks.
My contribution
I built the FastAPI service and its delivery baseline: model lifecycle, input validation, readiness behavior, structured logging, tests, pinned dependencies, and Docker packaging.
Public evidence
The code and CI demonstrate the service contract and quality gates. It uses the Iris dataset and is a reference implementation—not a claim of production ML ownership.
Read the repository

How I work

Product judgment, expressed in engineering.

  1. Define the useful boundary

    I start with the user’s job, the success condition, and the risks that should remain outside the first version.

  2. Design for failure

    Validation, timeouts, explicit errors, safe defaults, and review points are part of the product—not cleanup work.

  3. Make the work inspectable

    I prefer small interfaces, reproducible setup, tests around contracts, and documentation that records tradeoffs and limitations.

Background

A quality-engineering foundation, applied to current AI systems.

My professional history spans medical technology, financial data, enterprise software, and e-commerce. That work built a lasting bias toward clear contracts, automation, and dependable delivery.

Today I apply that foundation to backend and AI-enabled products. I am most useful where a team needs both hands-on implementation and careful thinking about scope, reliability, and what the evidence actually supports.

Professional history on LinkedIn Public code on GitHub

Contact

Interested in working together?

I’m based in Berlin. The clearest way to start a conversation is by email.

durotanja@gmail.com