Days of manual testing, done in hours.

I build test automation for product teams, or rebuild what you already have. Either way the result is the same: the checks that decide whether you can ship stop being someone's evening and start running on every change.

Four ways in, depending on where you are. Scope in flows, a calendar in weeks, and the code is yours at the end.

01 Assessment Within a week · €490, no VAT · credited in full Start here when you know testing is the bottleneck and not yet what to do about it.
- 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. 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
- The 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 From two 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.
- An AI system built for your application, not a generator pointed at your screens. It stays after I leave
- 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 proves the data underneath, not just 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 stops meaning a neighbour
- A run on every change, with results in the tracker your team already reads
- A gate that stops a test which proves nothing from being 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 From two 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.
- An AI system built against your application. 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 prove nothing, 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 means a defect again
- Gates installed, so the same drift has to get past one first
Two numbers: how many tests could detect a failure before, and how many can after. 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. Most vendors price this as a separate line item.
Trying to merge a test that asserts nothing, and watching it get stopped.
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 could detect a failure before, and how many can 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. 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 daily, not something I did a few years ago and now consult about.

Web, API and mobile. 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.

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 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 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? 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.

The detail, if you want it

Questions I get asked

Why not just hire a QA engineer?

Setting this up needs senior judgement. Maintaining it does not. A permanent senior hire means paying senior rates forever for a steady state a mid-level engineer can carry.

Building a suite is a burst of work. Maintaining one is not forty hours a week. Test maintenance eats 30–50% of a QA engineer's time in ongoing sprints, and most of that goes on repairing tests that broke because the interface changed rather than because the feature did.

Where a permanent hire is the wrong instrument:

The product is in maintenance mode, or the main flows are already built. The work is regression, and regression is an asset you build once.
The team is small, and there is nobody to manage a QA hire.
Hiring takes three to four months. The release does not wait.
There is no brief. With no tests and no baseline, a new hire spends their first months deciding what to test at all.

If you have a compliance mandate that requires a named person in a QA role — health, finance, government — hire. Nothing here substitutes for that.

We already generate tests with AI. Why pay for this?

Generation is free, it ships inside the framework, and I use it. On a legacy application it produces code that looks correct and does not run — the selectors are plausible and do not exist. What you are paying for is the layer that makes generation reliable.

It also has no memory between runs, so it rediscovers the same traps in your application every time. Written down once, they are known.

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

It gets cheaper. Your engineer answers half the questions in the Assessment, which shortens it. The build is done alongside them and handed to them. A mid-level engineer is enough to keep it alive afterwards, so having one already puts you further along than most.

Why not an agency, or a managed testing service?

Different products. A managed service prices as a subscription that grows with your test count, and the machinery stays theirs. 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?

Invoice on delivery, payable in 14 days, 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.

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. That covers the work on this page.

Sitting outside it: iOS-native automation, security testing and penetration testing, and manual test execution sold by the month. For the first two the right answer is a specialist and I will name what to look for; the third 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.

I reply in English, Slovak, Ukrainian or Russian. 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.