Confidence does not come from more tests, more automation or more AI alone. It comes from understanding risk, building quality into engineering, using the right people and practices, and having trustworthy evidence.
OK Tech is a new firm. We do not have a wall of client logos or a stack of case studies yet. So judge us on what we can show now.
How we understand the problem, the evidence we use, the people we put around it, the way we price, and what lands in your hands once the work starts.
We are paid to help technology teams deliver better. Sometimes the immediate answer is more capacity. Sometimes it is specialist expertise. Sometimes it is changing the system so repeated effort disappears. We do not confuse activity with impact. A test suite is useful when it changes how the team works.
Our promise: we help technology teams release software with confidence.
Confidence comes from understanding risk, building quality into engineering, using the right people and practices, and having trustworthy evidence.
Capacity, expertise and transformation are not the same product, and we label them honestly. The label should tell the truth about what the work is expected to achieve.
Manual QA teams, QA engineers, SDETs, automation engineers, developers, infrastructure specialists and technical leads.
OutcomeThe immediate delivery problem is covered by people we can stand behind, with clear ownership and expectations.
Founder-led or specialist support for investigations, workshops, architecture, release engineering, automation, infrastructure, AI adoption and incident analysis.
OutcomeA bounded problem moves quickly because the right senior practitioner is on it.
Assessment, baseline measurement, release confidence checks, automation, CI/CD, observability, process change and fixed-scope implementation.
OutcomeThe client becomes faster, safer and less dependent on repeated manual effort.
If manual QA is what keeps a release moving today, we can provide that team. As we learn the system, we will also show where automation, infrastructure, process or ownership could remove repetition tomorrow. The client decides the pace.
Every team sits somewhere on this path. We meet you at the stage you are actually at, and we are useful at all five.
People remain accountable for quality and risk.
Good architecture, testability, CI/CD, observability and sound practice come first.
Use automation and AI where they improve speed, coverage, insight or maintenance.
Model-generated claims are hypotheses until checked against evidence.
Six questions we answer with your engineers, your incident history and your pipeline data, not a slide deck. The answers become the baseline everything else is measured against.
If we disagree with a technical decision, we will explain the evidence and the consequence we expect. If you choose a different route, we will record that decision and execute it properly. If the decision makes the agreed outcome impossible, we would rather stop than keep billing against an outcome we no longer believe can be reached.
Capacity is quoted by role, seniority and duration. Consulting and transformation work is priced against agreed outcomes, with a written scope and baseline before anything begins. Re-measurement is part of the work, not an extra.
Quoted by role, seniority and duration.
Day-rate engagement for investigations, workshops, architecture and other bounded problems that need a senior practitioner.
Fixed fee, four weeks. Measured baseline, ranked failure modes, a costed 90-day plan, and initial release confidence design.
Fixed fee for each agreed outcome.
Included with transformation work.
For fixed-scope improvement packages, if the agreed measure has not moved by the agreed date, and the agreed access and assumptions have held, we keep working at our own cost until it does or refund that work package.
An assessment runs four weeks. Every deliverable is dated, has an extraction method beside it, and is created in your systems.
Four checks, each with a standard, a reason to exist, and a named person who decides when it is not met. Agreed with the engineers who will live with them.
"A check without a clear decision attached to it is just a metric."
These were written for us before they were written for you. If a principle only works when it stays private, it is not a principle we should keep.
Every engagement should be able to name the problem it is solving. Activity alone is not the result.
Immediate fixes matter, but repeated failure needs a cause, an owner and a commercial decision.
Write runbooks, release checks, templates and reasoning so another engineer can run the routine.
We measure before we argue and we make it safe to change position when new evidence appears.
We advise on things we can build, debug or operate. Strategy should leave something working behind.
Headcount, automation and AI all have a place. Use the right one for the current need.
The elegant answer is not always the right answer if the timing, cost or risk is wrong.
The goal is not to become indispensable. The client should know what they will own and how we will prove handover.
We embrace AI, but we do not sell AI as a substitute for engineering. We help clients use it where it creates leverage while preserving human judgement, accountability and evidence.
Develop skills, judgement, curiosity and ownership.
Build testable systems, reliable pipelines, observable production and sustainable automation.
Use automation and AI to remove repetition, accelerate investigation and increase useful feedback.
Validate assumptions and make release risk visible.
Greater confidence to release.
On one automation platform, whole suites would occasionally fail without an obvious product change. Deeper telemetry showed that the problem was not the tests or the product, but an under-resourced execution environment. We fixed the environment rather than tuning the tests around unreliable infrastructure.
Before trusting a test result, make sure the platform producing it is healthy.
For transformation work, the finish line is written on day one. We name the capability you will own, the person who will own it, and the condition that proves handover is complete.
Handover is complete when your own people can run the routine twice with us present and once with us out of the room.
We reuse anonymised patterns such as release confidence designs, extraction methods and failure-mode taxonomies. We do not reuse incident narratives, production data, names or anything that could identify your organisation.
Production access is read-only and any exports are deleted within 30 days of handover.
Founder-led and practitioner-led means a problem can be followed from product to pipeline to infrastructure without turning every boundary into a hand-off.
One team follows the problem end to end, without hand-offs at every boundary.
Founder-led means the people you meet in the first conversation are the people who do the work.
Ten years building quality engineering, automation and release systems across mobile gaming, high-scale SaaS and media. Recent work includes release confidence, CI/CD, observability, incident analysis and AI-assisted engineering.
Quality consultant, speaker and co-author of Contract Testing in Action. Brings a systems view of testing, observability and modern quality engineering.
Take your last three production incidents. For each one, name the earliest stage that could realistically have caught it: definition, architecture, build, deployment or observability. Nothing you enter here leaves your browser.
Be honest about "realistically". The answer that flatters the process is usually not the earliest one.
That is usually the right place to start a Quality Health Check.
[email protected]