Tests for teams that ship with AI.

What your agent actually did, read back from the system it wrote into. And which AI-written tests need a human look, flagged in CI on every pull request.

Failures caught in the build instead of reported by a customer, and review time spent only on the tests that need it. The first step is one week inside your product, for €490.

For teams that ship with AI

Agents in your product. When your agent says the booking, the refund or the update in another system is done, I read the record back from the system it wrote into: it exists, exactly once, with the right values, and a retry does not create a second one. Plain API and database reads, run on every release, so a wrong write fails the build instead of reaching your customer. Whether the agent should have acted at all is a question about the model, and a different kind of test. Built as Coverage.

AI-written tests in your codebase. A coding agent asked to fix a failing test will often make it easier to pass. Written rules on what your coding agents may change, and a CI gate that flags which AI-written tests need a human look: it catches the known ways a test can pass without being able to fail. Before handover I break what each test checks and check whether it goes red. Built as Coverage on a new suite, or Rescue on one that has drifted.

Both start with the Assessment. Everything runs in your repository and your CI, on the tools your team already uses.

01 Assessment One week, five working days · €490, no VAT · credited in full Start here. One week inside your product, ending in a scope, a calendar and a price for what to build.
- Every action your agent takes in another system, with how its result can be read back and whether a test account exists there
- Where AI writes your tests: which of them a person still has to look at
- Every flow I can reach, named and listed — and the ones I cannot, named too
- Every flow ranked by cost of failure: your numbers, my ordering
- A trap catalogue: what will fight the tests here, checked against the running application, priced in hours where it is confirmed
- The flows I would not automate, and why
- Tools chosen for this stack, and the ones I rejected, named
- Two or three options, each with a scope in flows, a calendar and a price
- The in-house version: where to start, in what order, what to avoid
- The state of your test data and environments
- Specification gaps: where nobody has decided how the system behaves
The fee comes off anything you commission from it within six months. The document is yours either way. Read the Assessment in full Get a price for this
02 Machine pass From one week For a product that is large, not yet live, and growing faster than anyone can test it by hand.
- Scenarios come from your own documentation — what the system is supposed to do — not from a model guessing at intent from the screen in front of it
- My agent that writes the scenarios is never the one that runs them, and whoever runs them cannot rewrite them
- Every finding is reproduced a second time, in a new session on fresh data, before it reaches the report — with the steps, the evidence, and what it is a defect of: the product, or my own expectation
- Every check that reports something missing is run again against a case where it is present, and both results go into the report
- Where the documentation, the product and the data it is fed disagree, the disagreement is the finding — including when the fault turns out to be in the data rather than in the code
- Where the product has no documented rule for the behaviour, it stops and asks
- A list of what it could not reach, with the reason, shipped with the report
- Runs against a test environment you provide, under permissions agreed in writing
Your testers open a report instead of an empty checklist. The first run lands in days. Read the machine pass in full Get a price for this
03 Coverage Usually two to four calendar weeks The calendar follows the number of flows, agreed after the Assessment For a team whose releases wait on a manual pass nobody has time for, or whose agent writes into systems nobody reads back.
- Your application written down once: its data, integrations and known traps, reused by every check and by your coding agents after I leave
- Agent actions checked where they land: the record read back from the system your agent wrote into, on every release
- Flows agreed after the Assessment, chosen by what a failure costs you
- End to end: interface, API and the database underneath, so a green test has read the row in the database, not only the screen
- Test data the suite creates and cleans up itself, instead of a shared account somebody else edits
- An isolated environment on every run, so a failure points at the code or the test, not at a neighbour's data
- A run on every change, with results in the tracker your team already reads
- A CI gate that flags the known ways a test can pass without being able to fail, before it is merged
- Four numbers at handover, measurable again by someone who has never met me
The suite is yours. Open source, no licence, nothing of mine you keep paying for. Read Coverage in full Get a price for this
04 Rescue Usually two to four calendar weeks The calendar follows how many tests exist; named once I have read the suite For a suite that exists, runs, and nobody trusts any more.
- Your application written down once, so every check reuses it. Your suite sorted into what works, what can be repaired, and what was never checking anything
- Every test read for one question: does this assertion tell a working system from a broken one?
- The commits that got it here, named — a raised timeout, an expectation edited to match the output, a test skipped during a release week
- Tests that could not fail, listed with the reason, and deleted
- Tests that are broken but repairable, repaired
- Flaky tests quarantined under a written policy instead of a silent retry
- The environment removed as a variable, so a red run points at the code or the test, not at shared data
- Gates installed, so the same drift has to get past one first
Two numbers: how many tests went red when what they check was broken on purpose, before the work and after it. Read Rescue in full Get a price for this

None of these ships as a package. Scope, calendar and price follow from the application — the seven questions at the bottom of this page are what I need to give you all three.

What is included

In all four: a scope in flows with written exclusions, and ownership of what is created.

Different engagements leave different things behind. An assessment leaves a document. A machine pass leaves a report on every build. Coverage and Rescue leave a suite you own and run. Not every item below applies to every engagement, and which ones do is set out in the proposal, before anything is signed.

How you check each one

A written recommendation, with the options I rejected and why.
A ranked list you can argue with. If the order is wrong, you will know before a line of code is written.
Reading entries you recognise from your own bug history.
One page naming what is in and what is not — cloud subscriptions, VPN access, third-party sandboxes, and how a change request is priced. Signed before work starts.
Yours in full on final payment: the tests, page objects, CI configuration, the trap catalogue and element record built for your application, the fixtures and the runbook. Open source tools, no licence, nothing of mine to keep paying for.
The templates and orchestration I bring to every project stay mine. You get a perpetual, free right to use them inside this codebase, its successors and any acquirer of it — no expiry, no renewal, nothing further to pay. They are not resold or moved to a different product.
At handover your engineer adds a new flow themselves, while I am still there and not helping. If it does not work, the documentation is not finished and I finish it.
Reading it. Structure, patterns, fixtures. The part that decides whether the suite is alive in a year.
Run the suite twice in a row. Then twice at once. The same result both times.
Two runs at the same time, neither affecting the other.
Opening a pull request and watching it run.
A failing run appearing where your team already looks, without anyone forwarding it.
Trying to merge a test with no assertion, or one switched off, and watching it get stopped.
Running the agent's action in a test account, then reading the record back yourself through the target system's own API: one record, the right values, and the same after a retry.
A written rule for what happens to an unstable test: not a retry that hides it, and not a skip that removes the coverage without telling anyone.
Numbers you can measure again yourself, three months on, with somebody who has never met me.
After a build: how long a full regression takes, how many revenue-carrying flows are covered, how many production defects landed in covered ground, and how long a red run takes to fix.
After a rescue: how many tests went red when what they check was broken on purpose, before and after. That is the number the work is judged on.
Naming them yourself. "Log in, place an order, cancel an order" — you can count those. On a rescue, that means the coverage that already exists, brought back to working order; coverage that has to be written from scratch is separate work with its own scope.

How it works

You answer seven questions Below, in a few minutes. What the application is, your stack, and what has been going wrong.
I read it Against the paths that carry your revenue — including what I would not automate, and why.
You get options Two or three, each with a scope in flows, a calendar estimate and a price range. The exact price for a build follows the Assessment. Plus a start date and an expected finish date.
You decide Or you take the reply and build it in-house, and owe me nothing.

A reply in one working day. No proposal deck, no discovery phase billed by the hour, and no call needed before you know what it costs.

Who is writing this

Taras Mylyi. One engagement at a time. Test automation is what I do every day. On one project, creating and maintaining tests took about half the effort, and full regression went from about two days to under an hour.

Web, API and Android. The suite is written in whatever your repository already runs — Playwright, Cypress, Selenium, REST Assured — in TypeScript, JavaScript, Java, Kotlin or Python. That list is what comes up most often, not a limit. If yours is not on it, ask.

The trap catalogue did not start as a method. It started because I kept meeting the same things — a control that is not the control it looks like, a table whose columns move between screens, a value that is blank in the database and a dash on screen — and stopped trying to hold them in my head.

My own AI tooling changes nothing in your code without your approval.

No dependency on me. If your engineer cannot add a flow six months on without calling me, I built the wrong thing.

Show me the application.

Seven questions. No discovery call — the answers here do the same job, and you keep your calendar.

Only three answers are required: your stack, the list of things people or your agent do, and what a failure costs. An incomplete form beats an unsent one.

Not ready to scope anything? Write anyway. I will tell you what I would do first, and you can come back when it matters.

A link to the application, or to staging

Your stack: front end, back end, database required

Name five to fifteen things a person, or your agent, does in your product. One per line. required

For each of those: what happens if it silently breaks for a day? One sentence each. required

Is anything automated already? Nothing Yes, and nobody trusts it Yes, and it works

What broke most recently, and how did you find out?

Staging with database access, and test accounts in the systems your agent writes to? Yes No Not sure

Your mail client opens with everything filled in — press send there. Nothing leaves this page on its own, so if the client did not open, the address below works just as well.

What gets composed — in your mail client, not sent anywhere by this page

This form builds an email in your own mail client — there is no form service behind it, no endpoint, and nothing reaches this server. It needs JavaScript. With scripts off, write to the address below and answer the seven questions above in your own words.

If staging does not exist, say so — it changes the scope or the calendar, and I will tell you which before we start, not on week three.

Outside read

A free outside read of your product.

One page on where a release is most likely to cost you, made only from what is public: a sign-up or trial of my own, your documentation, changelog and status page, and reviews. No access, no call.

On the page, in this order:

Your flows, named in your product's own words, and the count behind them: how many can be seen from outside, how many I went through, and how many I could not reach.
The first three to five of them by what a failure would cost, each next to the public signal that put it there.
Two or three observations, each reproduced twice on a fresh account, with the steps.
What will fight automation in this product in particular, checked against the running product.
What cannot be seen from outside. The Assessment covers that part.

For products a person can sign up for or try without a sales call, with documentation in public. If yours needs a call first, the reply says what would work instead.

A reply in one working day. The page is yours to keep, and nothing follows it unless you write again.

What gets composed — in your mail client, not sent anywhere by this page

This form builds an email in your own mail client and needs JavaScript. With scripts off, write to the address below with a link to the product and the one thing that must not silently break.

What the email carries, and how long I keep it: the privacy page.

The detail, if you want it

Questions I get asked

We already evaluate our agent. Does this overlap?

Agent evaluation tools mostly score the agent's trace: which tool it called and what it answered. These checks read what actually landed in the system the agent wrote into, through that system's own API. The two answer different questions, and the checks run alongside whatever evaluation you already have.

Does this replace a QA hire?

No. It is a bounded build with a handover, and it works the same with a QA engineer on the team or without one. If your product needs a named person in a QA role, for a compliance mandate in health, finance or government, that person sits alongside it.

Our coding agents already write the tests. Why pay for this?

Keep them writing; I use them too. A coding agent asked to fix a failing test will often make it easier to pass, and the change reads like a fix. What you get here is written rules on what your coding agents may change, and a CI gate that flags which AI-written tests need a human look: it catches the known ways a test can pass without being able to fail.

Your application's traps are written down once, so an agent does not rediscover them on every run.

We already have a QA engineer. Does this still apply?

Yes. Your engineer answers part of what the Assessment would otherwise have to find out, which leaves more of the week for the product itself. The build is done alongside them and handed to them. A mid-level engineer is enough to keep it alive afterwards.

Why not an agency, or a managed testing service?

Different products. A managed service is usually priced as a subscription that grows with your test count, and the machinery usually stays with the provider. What you get here is a system you own outright, once. If you would rather never think about it again, a managed service is the better fit and I will say so.

What if we do nothing?

Usually the honest answer for a while. Manual testing works right up until the point where the product outgrows the number of hours in a release week, and most teams are further from that line than they think.

What tells you the line is close: the manual pass has started being shortened rather than done, the same area breaks twice, and nobody wants to be the one who says the release is not ready. None of those is an emergency on its own. Together they mean the decision has already been made by the calendar, and you are choosing when to notice.

What does it cost?

The Assessment has a fixed price — €490 — because it has a fixed scope. A build does not. What it costs follows from the application rather than from the number of flows alone — the disclosure below on how I count sets out the range, and why it is that wide. So the price follows the Assessment, and the reply shows how the number was reached, including the parts that make it smaller.

How does invoicing work?

The Assessment is invoiced once we agree a start date. A build is invoiced on delivery. Both are payable in 14 days, by bank transfer. No VAT is added. EU business clients: invoices are issued under the reverse charge mechanism, so I will need your VAT number.

What happens if something breaks after handover?

Two different things, priced differently.

If it was broken when I handed it over, I fix it. Thirty days from handover, no charge.

If your application changed and the tests need to follow, that is new work. Support covers it: a named owner while your team learns the suite, a few hours a month, two working days to respond. Optional, priced with the project, and it runs for a fixed three months from handover. It ends on that date unless you ask for more.

How I count: the flow, and why not test cases

A flow is one end-to-end user path with business meaning and a checkable outcome. Log in. Place an order. Create an employee record. Export a report. Reset a password.

For an agent, the unit is the action: one thing it writes into another system, with a record that can be read back. Book a visit. Issue a refund. Update an order.

One flow is, very roughly:

Spec file: 1
Test cases: 2–5
Assertions: 5–20
Hours, on a clean single-page application: 3–8
Hours, on legacy with traps: 8–20

Flows are the unit you can verify yourself. "200 scenarios" is not checkable; "these ten things work" is, and at the end we can both agree on whether they do.

The spread between 3 and 20 hours is the difference between an application with stable test attributes and one where every postback repaints the DOM and a custom widget hides the real input. It is also why the price follows the Assessment rather than the enquiry.

What I take on, and what sits outside it

Web, API and Android, in TypeScript, JavaScript, Java, Kotlin or Python, against relational databases and the APIs of the systems your agent writes into. That covers the work on this page.

Sitting outside it: evaluating the model itself (whether the agent should have acted, or how good its answers are), iOS-native automation, security and penetration testing, and manual test execution sold by the month. For the first three the right answer is a specialist and I will name what to look for; the last is not a product.

One project at a time. If I am busy, the reply carries a start date.

Get in touch

Email is the whole process. The seven questions above are the fastest route, and a few paragraphs in your own words work just as well.

taras@mylyi.dev

Within one working day you get two or three routes, including the cheapest one that would actually work: scope for each in flows rather than hours, a timeline in calendar weeks, and a price range. The exact price for a build follows the Assessment.

I reply in English, Slovak or Ukrainian. Bratislava, Central European Time — remote. Written replies within one working day. Calls by arrangement, and there are few of them: the work is scoped in writing and reported in writing.

Writing commits you to nothing. If you take the reply and build it in-house, that is a good outcome and you owe me nothing.