--- source_url: "https://tesai.app/?utm_source=openai" title: Tesai — QA and delivery consulting that makes releases boring mirrored_at: 2026-08-17T13:03:00.667Z host: tesai.app cited_in_42a: true mirror_canonical: "https://index.42a.ai/tesai.app/index__q__utm_source_openai" --- > **Original source:** https://tesai.app/?utm_source=openai stage 01/6Symptoms ## Your team got faster. Your releases did not. AI moved the bottleneck. It did not remove it — it pushed it downstream, into review, testing and the release itself. If two of these are yours, we should talk. more-prs Twice the pull requests, the same release cadence. review-queue PRs wait longer in review than they took to write. escaped It passed CI, passed staging, and broke in production anyway. carryover Half the sprint carries over, every sprint. date-slip You pad the release date by two weeks and it still slips. no-signal You can feel the bottleneck. You cannot show it as a number. None of these are tooling problems. They are process problems wearing a tooling costume. stage 02/6What changes ## The tempo stops depending on heroics. This is the whole job. Not more tests — a shorter path from merged to shipped, and a date you can hold other people to. before after before Today Merged anyway. It is probably fine. A task goes into testing and disappears for a week. · Release dates are given with two weeks of padding, and still slip. · You hear about the bug from a customer. · You argue about where the time goes. after Three months in Green means green. Ship it. Most of the checking happens in the pipeline, in minutes, before review. · The path from merge to production is the same every time, so the date holds. · You hear about it from the pipeline, before it merges. · You look at lead time, cycle time, and time in review — and argue about the number. stage 03/6Engagement models ## How much do you want to own? The same team either way. The shape changes with how much of the problem you hand over. embedded Embedded team Our engineers join your team, your standups, and your board. Managed by us, accountable to you. Scale up or down with a month of notice. Best when: you need capacity now and headcount is slow. · Monthly · Your process · Scales audit Delivery and QA audit A fixed-scope, fixed-price review of where your delivery time actually goes: the board, the process, the pipeline, and the testing inside it. You get ranked findings, measured cycle times, and a roadmap you could hand to another vendor. Best when: you know the tempo is wrong but not why. · Fixed scope · 2–3 weeks · Deliverable delivery-setup Delivery setup We design and implement the process layer: definition of done, environments, gates, branching, release cadence, and the metrics that tell you whether it worked. Best when: the tests are fine and shipping still hurts. · Project · CI/CD · Handover stage 04/6What you keep ## It all lands in your repository. Not a slide deck and not a portal you lose access to. Every engagement produces working files that stay yours. audit The audit, in writing What we found, ranked by what it costs you. Every item points at a commit, a failed run or a timing. suite A suite your team can read Playwright and TypeScript, in your repository, reviewed through your normal PR process. No vendor format. gates Gates that actually block The checks that decide whether a change may merge — plus the flake policy that keeps them honest. runbook The release, written down Definition of done, the checklist, who does what when it goes wrong. The part that lived in one person’s head. metrics Numbers instead of opinions Lead time, cycle time, where work actually waits. Wired to your own board, so the next planning argument has data in it. You own all of it from the first commit. If we stop working together tomorrow, nothing breaks and nothing is withheld. stage 05/6How it runs ## Audit, build, hand over. A fixed shape so you know what you are buying. Each phase ends with something you keep, whether or not you continue. assess Week 1 — Audit We read the code, sit in your standups, pull the history off your board, and run your release once with you. No questionnaires, no maturity matrix. We measure where the time goes and look at what actually happens. You keep: Written findings ranked by cost, with the current numbers build Weeks 2–6 — Build We fix the top of the list. Usually that means a working suite on CI, a release checklist that is not tribal knowledge, and bug reports that stop bouncing. You keep: A running suite, gates in CI, documented process handover Ongoing — Hand over Your engineers write and fix tests themselves. We stay for review and the hard cases. The goal is that cancelling us should be uneventful. You keep: Runbooks, training sessions, clean exit stage 06/6What we cover ## Every discipline a release depends on. Not a resource pool and not a rotating bench. One team on one contract, covering the three things that actually decide whether a release goes well. delivery Delivery and release engineering The part nobody owns: how work becomes a release. Definition of done, quality gates, branching, environments, and the flow metrics that turn a planning argument into a number. Lead time / cycle time · DORA metrics · Quality gates · Trunk-based / GitFlow · Release trains automation Test automation The machine that takes the queue out of testing. A suite your engineers can read and maintain, running on every pull request, with flake under control so a red build means something again. Playwright · TypeScript · pytest · GitHub Actions · GitLab CI exploratory Exploratory QA and test design What automation structurally cannot find, kept off the critical path. Chartered sessions, real test-design technique, and bug reports a developer can act on without a follow-up call. ISTQB · Charter-based testing · Jira / Linear · Postman · Charles Take one discipline or all of them. Most engagements start narrow and grow.