Artem KiselevStart the health-check

If the system is breaking, that page is Rescue.

Your system works. Now change it faster and trust every change.

It already runs, and it rarely breaks. Whether the changes come from you, your people or your agents, you are still the one who checks them, and you cannot yet say the system is reliable and safe enough to lean on harder. A health-check names the few things in the way and the order to remove them, and the Speedup step removes them.

Start the health-checkme@artkiselev.dev
A person operates a crane and a robot fits a missing piece into a cube standing in scaffolding
Artem Kiselev

Former tech founder helping agencies and service businesses turn vibe-coded internal tools into software they can rely on.

Recognize this?

It works. People use it, tests exist, and regressions are rare. What you cannot say yet is that it is reliable and safe enough to lean on harder, and you would like someone besides you to work on it.

A person sits at a table working through a tall stack of sheets while three robots wait in line, each holding a new sheet
  • Everything still depends on me. Even with more people and agents on it, every change ends with me checking it.
  • I do not know how safe it is. Customer data and keys live in there.
  • I think it holds, but I cannot show it before more traffic or more spend.
  • A new module means going back to check the old ones, and the links between modules sometimes do not meet.
  • Integrations fall off, then come back, with no one sure why.
  • I want someone besides me working on it, and I do not know how to let a person in, or an agent, without creating a risk.

What it costs while it runs on one person

None of this is a crisis today. It is why next month costs more than last month.

Reliability you cannot show. You find out whether it holds when real traffic, bad input or a failed integration arrives, with customers watching. There is no earlier way to find out.

Safety nobody has looked at. Keys, permissions and customer data were set up so the tool would work, not so they could be checked. You are trusting a setup that no second person has read.

One person is the only way in. While you are the only one who can change it safely, every change waits for your time, and the tool stops growing when you stop.

You become the tester. Agents and helpers produce changes faster than one person can check them, so the checking falls back on you.

What actually slows you down

The system is missing the practices that let more than one person, and more than one agent, change it without getting in each other's way. On the method page that is the move from stage 1 or 2 into stage 3. The report builds a plan toward the stage you are aiming at. Stage 3 on the method page.

A robot reads a very long sheet of paper that spills onto the ground

The rules should live in the repository

The next session, yours or an agent's, starts without them. Sensible local edits pile up, and the next change costs more than the last.

A person and a robot build a sand cube inside a sandbox

There should be a safe place to try a change

Every experiment touches the system people already rely on. That is why a small addition turns into an evening of checking.

A robot lifts one cube off a conveyor and looks at it through a magnifying glass

Changes should be checked against the last one

Debugging drags on because a practice is missing, not because you are not trying hard enough.

Three steps, each one stands on its own

You can stop after the first one, and you keep everything it gives you. The price of the next step is fixed and named for your system, after the health-check.

Health-check$1,900 · 5 business daysI read the system with read access to the repository, use the tool as a user, and talk to you twice. You get a two-page note, the full report with every problem and how to solve it, and the tasks you can give to an agent right away. Nothing is changed.Speedup$5,000 to $15,000, fixedI fix what the report found, on your running system, one practice at a time and each one checked: reliability, safety, room for more people and agents.Retainer$1,000 to $2,500 / monthI keep the rules and checks current, review what your people and agents change, and answer on the day something matters. Everything keeps running if we stop.

AHealth-check

$1,900 · 5 business days
Who it is for
You own an internal tool that works, that you built with AI tooling, and that you are not sure is reliable and safe. Or you want a second person, or agents, working on it, and you do not know how to let them in without a risk.
What I do
  • Read the system: read access to the repository, the tool as a user, and two conversations with you.
  • Check reliability and safety against a written list: tests, environments, keys, data, libraries, backups, monitoring.
  • Find what keeps a second person or an agent from working on it safely, and the order to remove it, toward the stage you are aiming at.
  • Mark the problems an agent can fix right away, so you can hand them over as they are.
What you get
  • A note, two pages. Page one is the maturity of the system, the stage you are aiming at, the conclusion and the next steps. Page two is an Author's comment, in my words, on the next weeks and who does them. I confirm that page. An agent may draft it.
  • The full report. Every problem I found, each with the way to solve it, in the order to take them. Written so you can hand it to your agent for reading and for questions.
  • Tasks ready for your agent. The problems that an agent can fix are marked in the report. Give them to your agent one at a time and you get a quick result. Each one says what to check afterward.

Read the example note.

Price and terms
$1,900. You keep the report whether or not you continue. The next step is a fixed price, named for your system after the health-check.
Not included
Nothing in your system is changed, and I ask for no production access. Reading and judgment only.

BSpeedup

Fixed price, $5,000 to $15,000

This step fixes what the health-check found. You are paying for a system you can rely on and that more than one person can change, not for a list of findings.

Reliability
I put tests on the paths your income depends on, keep production apart from test, restore a backup once to prove it works, and tie monitoring to business impact with a quick way to undo. You know it holds because it was tried, not because it has not failed yet.
Safety
I move keys and settings out of the code, check your data and libraries against a written list, close the gaps that list finds, and write access down and test it. You get the list of what was changed.
More hands
A second person, or an agent, gets a working copy with test data instead of production keys, and a written guide on how to start. If it is needed, I set up CI/CD, so every change goes through branches, review and automatic checks before it ships, and an audit log shows who did what. They can start without putting you at risk.
Agents that keep the context
The house rules, the stack and the decisions live in your repository and load into every task. The agent stops starting from zero, and you stop being the tester.

How the work goes. The practices go onto the running system one at a time, each one checked, with no freeze. Work happens on a branch and a staging copy, with the keys you issue and can revoke.

Scope and timeline. Written down after the health-check, when there is something real to name.

Price and terms. Fixed price, not hourly, $5,000 to $15,000. The exact figure is named for your system after the health-check.

CRetainer

$1,000 to $2,500 / month

You do not need the retainer for the system to keep working. If we part ways, everything keeps running. The rules live in your repository, not in my head.

The system keeps changing, by your people and your agents, and the rules and checks have to keep up. This is an engineer who looks at it regularly and answers on the day something matters.

  • Monitoring the system, and responding when something matters.
  • Keeping the agent instructions, rules and checks current as the system changes.
  • Adding new practices as the system grows, one at a time, each one checked.
  • A fast answer on the day something matters, and a second opinion before you build the next thing.

Offered after the health-check, with a scope and a fixed price named for your system.

What the note looks like

An example note, with the Next steps block and the author's comment, and one task with its mode. It is an example of the form. It is not a client, and it is not a result. Read the example note.

A development environment that does not use the live databases

Only with an engineer

The change touches live data. An agent will not know what it broke until it is too late.

  • Before. A branch or a backup, and the tests on this part are green.
  • After. A change can be tried without writing to the live data.

A case goes on this site only with before-and-after numbers and written permission to publish. Neither is here yet, so none is promised.

What stays in your repository

Everything lands on your accounts, with your keys. If we part ways tomorrow, it keeps working and another engineer can pick it up.

Agent instructions
AGENTS.md

Hard rules
- Change billing math only
  with a matching test.
- Never read or write
  production data from a
  working copy.
- Record every decision in
  docs/decisions before
  finishing the task.

Format sample. Real redacted
files replace this when the
owner has given permission.
Who can do what

One page of roles and access, loaded into every task.

Checks on every change

Tests and gates that run before anything ships.

A test copy with test data

A place to try a change that is not the live system.

A launch checklist

What was checked before spend or a new audience.

A runbook

The incidents that actually happen, and what to do.

A decision register

What was chosen, and why.

Real fragments, redacted with the owner’s permission, belong here once they exist. The sample shows the format.

What I answer for, and where it ends

What I put in place, I check. Each practice goes onto a branch and a staging copy first, and counts as done when its check passes on your system. You get the list of what changed and why.

If something I changed breaks, I fix it. I answer for my changes, and the terms are written into the scope before you commit.

I say what I did not check. Every result states what was checked, what was fixed and what was left out, so you are never guessing about the gaps.

Not a security certificate. I check and fix against a written list. I do not run a penetration test, and nobody can promise a system that never fails. If you need a certificate, that is a different job, and I say so.

No promise of a multiple. I remove what is in the way. How much faster you go depends on what you build next, and I will not put a number on it.

Your decisions stay yours. What a role may see, what is worth building, and whether to spend on ads are business calls. I lay out the facts and the risk. You decide.

This page is not for you if

  • the system is still small enough that you can hold it yourself;
  • you need one fix, and you already know which;
  • you need a security certificate or a penetration test.

Questions I get asked

What people whose system already works ask me, and what I do about each one. The practices link to the method page.

I built it, but is it reliable and safe? Can I run ads?

Why it happens. It works on the path you tried. Nobody has looked at what happens under more visitors, bad input, a failed integration, or a leaked key, and there is no way to find out before the spend starts.

What I put in place

What changes for you. The Speedup step closes the gaps the check finds. Before you spend, you get a written account of what was checked, what was fixed and what remains, and a plain answer on whether to run ads now or after one more fix. It is not a certificate, and I cannot promise that ads will pay back, but the system will have been tried against the things that break it.

Can my people work on it without getting access to everything?

Why it happens. One account holds every key, so letting someone in means letting them into production, the data and the billing. Without review, one careless change reaches customers.

What I put in place

What changes for you. I set this up on your running system. A person gets a working copy and test data, not production keys. Their change passes the checks and your review before it ships, and you can see who did what. Access grows by role, only when the role needs it.

Do I need this if I am about to hire someone?

You need it if they would otherwise have to guess how the system is allowed to change. You do not, if someone is already working to rules you both trust. The health-check gives the new person a map and an order of work, and the Speedup step puts the rules, checks and a test copy in place before they start, so they begin on a system that holds. It does not replace the hire.

Why does the agent forget what we agreed?

Why it happens. An agreement made in a chat dies with the chat. The next session cannot see it, so the same decision gets re-made, differently.

What I put in place

What changes for you. An agreement is written once, in the repository, and loaded into every task. A rule that goes stale is caught by a scheduled review. A rule that matters is held by a test, not by anyone's memory.

Why do I have to ask the agent for every little thing?

Why it happens. The agent starts each task with no rules of the house. It does not know your stack, your naming, or what “done” means here, so it asks, or guesses, and you fill the gaps by hand.

What I put in place

What changes for you. You describe the goal in a sentence. The agent follows the house rules and runs the checks itself before it hands the work back. You review a result, not each step. Decisions that belong to the business still come to you, as they should.

Why not keep going on my own, or rely on my team?

From inside the system you and your agent miss whole classes of trap: rules that were never written down, a change that can only be tried on the live system, a check that does not exist. I find them and close them, so the time goes to the next feature and not to rediscovery. If your team is already handling it, the report says so, and you should not buy the next step.

Can I give the report to my AI?

Yes, so it can explain every finding and help you prepare questions. The tasks marked in the report you can give to your agent as they are, one at a time, and get a quick result. The rest are fixed in the Speedup step or by your own engineer.

Is this overkill for my size?

If the system is small, you still hold it, and you are not about to add a person, an agent or ad spend, then yes. Say that in the first note, and I will tell you not to buy it.

Will you rewrite everything?

No. The practices go onto the running system one at a time, each one checked, with no freeze. A system that is already in decent shape is a normal result of the health-check, and the report says so in those words. A rewrite is not the offer.

What about access, an NDA, and my data?

The same rules as the rest of the work: an NDA on request before access changes hands, and production access is not requested before a signed agreement. For the health-check I need read access to the repository, a look at the tool as a user, and two conversations. Write to me@artkiselev.dev if you want the NDA first. Access, NDA and your data

Start with the health-check.

A few questions about the system. I read them myself and reply with a fixed price and a start date before you pay anything. You keep the report, and you can stop there.

Start the health-checkme@artkiselev.dev

Write at 11:40pm on a Sunday if that is when you have time. I will answer, and it will be me answering.

Artem Kiselev. Former tech founder helping agencies and service businesses turn vibe-coded internal tools into software they can rely on.More about me