Projects

A cross-platform desktop client for SQL, NoSQL, object storage, and HTTP APIs in one workspace.

Problem

Working across a relational database, a document store, a bucket, and an API means juggling four tools — a SQL GUI, a Mongo client, an S3 browser, and Postman — each with its own mental model, and no way to see them together.

What I built

One client that unifies four connection paradigms behind a single interface: browse, edit, and query SQLite and PostgreSQL, MongoDB, S3-compatible object storage, and HTTP APIs side by side in the same workspace.

Why it matters

It removes the tool-switching tax during debugging — read a Postgres row, inspect the object it points at in S3, and replay the API call that wrote it without ever leaving the window.

An offline-first productivity PWA running a Rust/WebAssembly core in the browser.

Problem

The small daily utilities — markdown editing, data conversion, task tracking, image tweaks — are scattered across web tools that stop working the moment you lose connectivity, and quietly send your data to someone's server to do it.

What I built

A single PWA on a Rust-to-WebAssembly core, where markdown editing, data conversion, task management, and image tooling all execute locally on a draggable desktop metaphor — with Firebase sync as an opt-in rather than a requirement.

Why it matters

Compute-heavy work runs at near-native speed through WASM instead of round-tripping to a backend, and the default is that nothing leaves the device. Sync becomes a feature you choose, not the price of entry.

A local-first file manager with an embedded Ollama chat panel and chainable prompt workflows.

Problem

Asking an LLM about your own files normally means uploading them to someone else's infrastructure. And file managers have no concept of "run this prompt across these files" — every repetition is retyped by hand.

What I built

A Finder-style manager in Flutter with an embedded Ollama chat panel, a Quick-Look-style preview viewer, and a workflow editor for chaining prompts against local files — with inference kept entirely on-device.

Why it matters

You get assistant ergonomics over your own filesystem without the files ever leaving the machine, and prompt chains become reusable workflows instead of one-off questions.

A local Windows automation agent, driven from Telegram over an MCP tool layer.

Problem

Operating a desktop machine remotely means RDP or a pile of bespoke scripts — and neither is something an LLM can pick up and drive on your behalf.

What I built

A local agent that executes app, file, and system commands sent from Telegram, exposed through an MCP tool layer with authenticated real-time command handling and a local Ollama model in the loop.

Why it matters

The machine becomes agent-addressable — any MCP-speaking client can operate it — while auth on the command path keeps that from being an open door. This is the same MCP pattern I went on to ship in production at Syneca.