Egemen Soylu / Software engineer + creative technologist

I build systems, software, images and sound.

Engineering depth and creative practice, treated as one body of work — from enterprise data systems and modern backend architecture to moving image, creative code and music.

01 / Selected work

Different media. Same urge to make.

Selected public work across systems, moving image, music and experimentation. Engineering work appears here only when the publication boundary is clear and the project says something useful about how I work.

Explore all work →

02 / Engineering

Tools change. Engineering judgment compounds.

I do not divide my career into an embarrassing “legacy” chapter and a fashionable “modern” one. The technologies changed; the underlying work — data, boundaries, failure modes, delivery and maintainability — kept accumulating.

  1. Enterprise systems

    Oracle, PL/SQL, Forms & Reports

    Data-heavy business applications, relational modeling, stored procedures, reporting and systems where correctness matters because people actually run their work through them.

  2. Backend & distributed systems

    Python, APIs, services and operational thinking

    Backend engineering expanded the same concerns across service boundaries: interfaces, queues, performance, observability, failure handling and systems that need to keep behaving after deployment.

  3. Product engineering

    TypeScript, SQL, infrastructure and end-to-end systems

    Modern product work spans application architecture, PostgreSQL, Node.js/TypeScript, containers, cloud-oriented delivery, telemetry and the product decisions around the code — not only the code itself.

View engineering experience →

03 / Studio

The other half is not a sidebar.

Music, motion and visual experiments use many of the same muscles as engineering: structure, iteration, technical curiosity and the patience to make an idea concrete.

01

Moving image

02

Music & sound

03

Creative technology

04 / Working method

Understand the system. Then make the thing.

I tend to work from the whole system inward: understand the problem, expose assumptions, model the important parts, decide what must stay simple, then build and test the smallest version that proves the idea.

That approach applies whether the output is a backend service, a product workflow, an audiovisual piece or an experiment that may never become a product at all.

  • Evidence over labels. Show the work instead of ranking skills with percentages.
  • Constraints are design material. Legacy, performance, cost and operations shape the solution.
  • Build for reality. Deployment, failure and maintenance are part of engineering.
  • Keep room for play. Experiments are allowed to exist before they become useful.

05 / Contact

Have a concrete problem worth building around?

Software engineering, architecture, technical leadership, product work or a creative-technology project: the useful starting point is the problem and its constraints, not a list of buzzwords.

Start a conversation →