Products

Software products built from real problems

I create SaaS products, self-hosted tools and developer utilities. Some are commercial, some are open source, and some are still being validated.

Each card below carries a status badge; the panel alongside explains what each status means.

Status at a glance

Released
You can install it today. AlertLoop, Traceloom, Weft.
Validation
Being built and validated; product decisions may still change. SaaS for service businesses.
Planned
An idea with a shape, not a product. Virtual IT Director.

No product is described as released until it can be installed.

Everything I build

The full list, with current status

A product is listed as released only when you can install it today.

Open Source · Self-hosted

AlertLoop

Released

A self-hosted event and notification center for software teams.

Problem
Important incidents and business events disappear across logs, inboxes and disconnected channels.
Result
AlertLoop collects events, routes notifications to email, Telegram and webhooks, and makes delivery failures visible through retries, dead-letter processing and replay.
My role
Product definition, architecture, implementation direction and release management.
Stack
Go · SQLite or PostgreSQL · OpenAPI / Swagger · Docker.
Status
Community edition v0.1.0 released. Pro and Enterprise editions are planned, not built.
View project GitHub

Open Source · Developer Tool

Traceloom

Released

Structured JSONL event timelines, grouped by trace_id, without a heavy framework.

Problem
Plain logs lose the context that connects one request to everything it touched.
Result
Traceloom writes structured events to a JSONL timeline grouped by trace, so a single execution can be read as a story instead of scattered lines.
My role
API design, architecture, documentation and cross-language product strategy.
Stack
PHP · JavaScript / Node · Go. One shared event format.
Status
PHP v0.4.0, JavaScript v0.1.0 and Go v0.1.0 released.
View project GitHub

Open Source · PHP Engine

Weft

Released

A lightweight PHP 8.4 engine for quickly launching simple, content-first websites.

Problem
Every small site re-solves the same problems: clean URLs, locale prefixes, a correct head section, sitemap, spam-resistant forms.
Result
Weft hides that layer behind a convention-driven core (a page file is the whole route) with SEO, optional i18n, caching, tracing and form protection out of the box. Deliberately not a framework: no ORM, no DI container, no admin panel.
My role
Product definition, architecture, implementation direction, technical review and release decisions.
Stack
PHP ≥ 8.4 · Composer (golovanov/weft) · Vite · MIT.
Status
v0.1.1 released, alpha; pre-1.0 the API may change. This site runs on Weft in production.
View project GitHub

Commercial Product

SaaS for Service Businesses

In Validation

A product designed to help small service businesses in Latin America stop losing WhatsApp bookings while they are busy with clients.

Problem
Booking requests arrive exactly when the owner cannot answer immediately.
Result
The product is designed around recovered time, fewer missed bookings and reduced no-shows, not around the concept of a bot.
My role
Product, architecture and implementation.
Status
In validation. A working demo is being shown to potential clients; details stay private until the product is public.
Get in touch Read the build notes

Planned SaaS

Virtual IT Director

Planned

An early SaaS concept for small businesses that need practical IT guidance and ongoing technical direction without hiring a full-time IT director.

Problem
Small businesses (5 to 50 people) without in-house IT leadership have nobody accountable for IT decisions and for watching the boring but expensive IT failure points.
Result
Nothing is built yet. The concept is a SaaS that gives a small business ongoing technical direction, not managed IT services or IT outsourcing.
My role
Product definition.
Status
Concept stage: an MVP scope is defined internally, but nothing is built.
Tell me if this is your problem

Next

More is in progress

I'm developing additional SaaS products, developer tools and automation systems. New projects appear here only when they reach a stage where someone else can actually use them.

Follow the build notes

Product principles

How I choose what to build

Seven rules that decide whether an idea becomes a product or stays a note.

01

Start from a real problem

Every product starts from an operational or engineering problem I have actually hit, not from a market gap I read about.

02

Define the narrowest useful first product

The first version has to be small enough to finish and useful enough that someone would miss it if it disappeared.

03

Validate before expanding

Scope grows only after real usage proves the problem was worth solving. Not before.

04

Prefer clear value over feature volume

A product that does one thing predictably beats a product that does eight things you have to check.

05

Build systems that can become products

My open-source tools all started as internal solutions to my own problems before they became public.

06

Document failed assumptions

A wrong assumption is only wasted if it goes unrecorded. I write down what I expected and what actually happened.

07

Keep human ownership over AI-generated code

AI agents increase how much I can ship. Architecture, review and production quality stay mine.

Rule zero

If I can't state the problem in one sentence, I don't build it yet

Most abandoned side projects fail here, long before the first line of code.

Have a problem that should be a product?

Send a short description of what your business or team keeps working around. I'll tell you whether it's worth building, buying or ignoring.

Send project details View GitHub
OSS Want the free tools first? Free, open source, installable today LOG Curious how these get decided? Build notes, tradeoffs and failed assumptions