No long contract on a first conversation. Each stage is worth doing on its own merits, and each one is designed to make the next decision obvious rather than risky.
QA Health Check
No cost
For: Any team that wants an outside read on where quality actually stands.
Includes
Twelve-question maturity assessment you can take instantly, unaided
A thirty-minute conversation about your product, stack and release process
Written review: current maturity, risk areas, and what we would do first
Prioritised 30/60/90-day roadmap
Outcome
A written assessment you can act on yourself, hand to your own team, or use to brief any vendor.
We scope and price after the health check, in writing, against defined deliverables. If we do
not think we are the right fit for what you need, we will tell you that instead of quoting.
The path
What a typical relationship looks like
01Health CheckFree assessment and written roadmap.
02Readiness SprintTwo weeks, fixed scope, working suite.
03Managed QAOngoing ownership of release quality.
04Automation growthCoverage expands into the long tail.
05Quality EngineeringPerformance, AI evaluation, production signals.
Working principles
The commitments that go in the contract
These are not aspirations on a website. Each one appears in the master services agreement,
because a promise you cannot enforce is marketing.
Your repository, your code
Tests and frameworks live in your version control from the first commit. No proprietary runner, no vendor lock-in, nothing to migrate if we part ways.
Scope in writing, changes through change control
An MSA and a per-engagement SOW define coverage, release frequency, response windows and what counts as new scope. It protects you from vague delivery and us from unlimited work.
Maintenance is included, not invoiced later
A suite that is not maintained becomes a liability within months. Keeping it green and meaningful is part of the retainer, not a surprise.
Least-privilege access, always
NDA before anything technical. Scoped, least-privilege credentials. No production access unless the work truly needs it. Secrets in a manager, never in code or chat.
No customer data on local machines
We test with synthetic or masked data by default. If real data is genuinely required, it stays in your environment under your controls.
Honest release recommendations
If we think a release is risky, we say so in writing with the reasons. You make the call — but you make it informed, and the record exists.
Reporting
Four numbers, every period
Test-case counts and pass percentages are vanity metrics — they go up whether or not your
product is getting safer. These four tell you whether the engagement is working, and they
are the ones we report against.
Coverage
Which critical journeys are automated, which are still manual, and what moved this period.
Escapes
Defects that reached production, root cause, and the regression test now preventing a repeat.
Suite health
Pass rate, flake rate, runtime trend. The numbers that tell you whether the safety net still works.
Cycle time
How long a release takes to validate — the figure that should fall every quarter.
FAQ
Commercial and practical questions
What does it cost?
We do not publish rates, because a number without scope is meaningless — the same "automation retainer" can mean four journeys or four hundred. After the health check we send a written proposal with defined deliverables, coverage targets and response windows, so you are comparing something real. Setup work and ongoing work are priced separately and stated plainly.
What is the minimum commitment?
The health check commits you to nothing. A Release Readiness Sprint is a fixed two-week scope with no obligation afterwards. Ongoing engagements run monthly with a notice period we agree up front — typically short, because a partner who needs a long lock-in is telling you something.
Which time zones do you cover?
We work primarily in IST with deliberate overlap for European and US teams. Working hours and response windows are written into the SOW rather than implied. We will not promise round-the-clock cover we cannot staff.
How do you start on an existing codebase?
Read-only first: repository access, a walk through the product, existing tests and CI configuration, and your last few incidents. Incidents are the most informative artefact you have — they show where the product actually breaks, not where you assume it does.
What happens if we want to end the engagement?
You keep everything: the framework, the tests, the pipeline configuration and the documentation, all already in your repositories. We do a handover session and write down what is covered, what is not, and what we would have done next. No exit fee, no data extraction exercise.
Can you work alongside our existing QA engineers?
That is the most common arrangement. Your engineers hold product knowledge nobody external can replace. We usually take the automation build-out and regression execution so that knowledge gets spent on judgement instead of on repetitive clicking.
Start with a free QA Health Check
Answer twelve questions about how your team tests today. You get a maturity score, the three gaps most likely to cause a production incident, and a 30/60/90-day roadmap — whether or not you ever work with us.