I write software for people who need one specific thing to exist.

Most of what I build starts as somebody's sentence. A family that plays cards from four different houses. A phone that should stop handing over an hour to a feed. A folder of code that nobody trusts any more. The job is turning that sentence into something that runs, and then proving that it runs.

How I work

No dependencies where I can avoid them. Several of the projects on this site have a dependency count of zero, including a linter, two scanners and a game server. That is a deliberate cost I pay during the build so that you do not pay it later, when a package you never chose stops being maintained.

Verification over vibes. A screenshot is not proof. One of the case studies exists partly because a desktop app took perfect screenshots of a window that was never visible to anyone. Things get checked through the operating system, through probes running millions of hands, or by unpacking the built artifact and reading what is actually inside it.

Limits get written down. Every case study on this site names the part that is unverified. An Android call recorder I published states, in its README, the platform restriction that no application can work around, because a user finding that out on their own is worse than reading it first.

Handover is the deliverable. Source, build steps that were run on a clean machine, and a walkthrough. If the delivery only works while I am around, it was not finished.

What I use

Node and JavaScript for tools and the web, Kotlin and Java for Android and small servers, Electron where a desktop window is genuinely the right answer, and shell and Debian tooling when the target is a whole system. English and Turkish, both fine for the work and the conversation.

Where the code lives

Public projects are on GitHub: a Linux distribution, a linter published to npm, an Android recorder with releases, and more. Client work stays private unless you want it shown.

Read the case studies for the long version, or start a project.