Software rescue · Automation · New products

I fix, automate and build software for small and mid-sized businesses.

You work directly with the senior engineer who reads, fixes and ships the code. No account manager, no juniors, no rewrite by default, and the code stays yours from day one.

Send the URL and a few sentences. Within one working day you get a yes or no and the first thing I'd look at.

Get a free fit check See the three services

7+ years of engineering · A reply within one working day · Code you can read on GitHub

nobody-was-watching.log

Rescue · Automate · Build

Three kinds of work, one engineer

Different starting points, the same way of working: understand the problem, fix or build the smallest thing that solves it, and stay responsible for it in production.

01 / Rescue

Fix software that half-works

An app built with Lovable, Bolt, Cursor or by freelancers that works until real users arrive. I find what is actually broken, keep what works and make it safe to launch.

From USD 150

Describe what is broken How a rescue works

02 / Automate

Stop doing by hand what software should do

Requests lost in messengers, the same data typed into three tools, an import nobody trusts. I build the workflow behind it and make sure its failures reach a person.

Describe your process How automation works

03 / Build

Build a new product from scratch

A SaaS, an internal tool or a customer-facing web app. I define the smallest version worth building, build it and take it to production, in a repository that is yours.

Describe your product How a product gets built

Proof

Problems nobody sees until they cost money

Three real incidents from projects I worked on: what the business saw, what was actually wrong, and what I did about it.

Payments

The payment account closed ten days after launch

Situation. A small shop selling digital goods, delivered the moment a payment cleared. Ten days after real orders started, the payment provider closed its account.

What was wrong. Someone was testing stolen cards through the checkout. The shop recorded only successful payments; the rest of the evidence lived in the provider's dashboard and closed with the account.

What I found. The shop's own data was still enough to see the attack: one device behind 57 accounts in a week. A rule tested against the shop's real history would have raised the alarm four days before the last payment went through.

Read the case

Sign-in

The login emails stopped and nobody was told

Situation. Customers signed in with a code sent by email. For a week, the codes stopped arriving.

What was wrong. The background worker logged every failure, and nothing passed it on to a person. The business found out from a customer, a week later.

What I built. Failures now go straight to a channel the owner already reads, and the same rule covers payments, sign-in and every background job. The owner now hears about a failure while it is happening, not a week later.

Read the case

Automation

The automatic updates that kept switching themselves off

Situation. A property listings business imports prices and availability from developers' own files. The complaint: "I switch automatic updates back on, and they switch off again."

What was wrong. The importer had five separate ways to drop a developer, and it told nobody. For this business, a stale price means the product has failed.

What I built. A new import pipeline, in production since September 2026. A file that looks wrong is held back instead of applied, nothing can switch a developer off, and every failure reaches a person.

Read the case

Client work stays confidential.

I don't publish client names, logos or screenshots, and yours won't appear here either. What I can show instead: real incidents from projects I worked on, how they were found and fixed, and code you can read.

How I work

From unclear problem to production

Most projects don't fail on syntax. They fail on the wrong problem, an unclear boundary or a system nobody owns after launch.

Step 01

Define the real problem

I separate the actual business or engineering problem from the first proposed solution.

Step 02

Design the smallest viable system

I define the product boundary, architecture and validation path before scaling implementation.

Step 03

Own the decisions, direct the agents

Architecture, technical direction and review stay with me. AI agents increase delivery speed inside those boundaries.

Step 04

Test, ship and observe production

A feature is done when it works under real conditions, however its code was written.

Step 05

Turn the result into reusable knowledge

I document decisions, publish useful tools and convert lessons into stronger products.

AI increases my production capacity. It does not replace engineering ownership.
Roman Golovanov

Case studies

Incidents, written up in full

How each problem surfaced, what was actually wrong, what was decided and what it cost. No client names.

Case Studies ·September 2026 ·6 min

Case study: the automatic updates that kept switching themselves off

A property listings business imported prices and availability from developers' own files. The importer kept dropping developers and told nobody. How it was rebuilt so that bad files are held back, people's decisions stay theirs, and every failure reaches a person.

Case Studies ·September 2026 ·8 min

Case study: the payment account closed ten days after launch

Card testing cost a small business its card payment account a month after opening it. The provider's history went with the account. The shop's own data survived, and it turned out to be enough.

Case Studies ·August 2026 ·3 min

Case study: two requests, one payment

A checkout that could not tell a customer's second attempt from a network retry, and a balance debit where the same ambiguity moved real money. What the fix actually was.

Case Studies ·August 2026 ·4 min

Case study: the login emails stopped and nobody was told

Login emails were sent by a background worker. The worker failed and logged every failure. The application kept answering 200, and the business found out a week later from a customer. What the audit after it looked for, and what else it found.

View all notes

I also build my own products and publish open-source libraries, including Weft, the PHP engine this site runs on. Products Open source

About

Product thinking. Engineering ownership. Real delivery.

I'm a product-minded software engineer with 7+ years of hands-on development experience. My work spans backend systems, APIs, web applications, integrations, automation and product architecture.

I'm most useful when a project needs someone who can understand the problem, make technical decisions and move the product forward without a large team.

Today I build my own products, publish open-source tools and take on client work: new systems and ones that need stabilizing.

Software that half-works, a process that runs on manual work, or a product to build?

Send a short description of the situation. Within one working day I'll tell you whether I can help and what the first useful step would be.

Describe your situation

RES Something is broken Software rescue · From USD 150 AUT A process to automate Requests, data and follow-ups that run by hand BLD A product to build A new SaaS, internal tool or web app