Project pipeline-ci-faster-and-stable-project · revised 11 October 2026
Project
Bring one repository's CI to an agreed duration and a reliable run history
We agree a duration target and the causes in scope, then deliver one repository's CI inside that target with a clean observation window and a final summary of every change.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the scope, the price and the terms in writing.
The result you are buying
A pipeline gets slow and unreliable for several reasons at once: a cache that never hits, a monorepo that builds everything, jobs that hang or run out of memory, and a handful of tests that fail without a cause. Fixing one in isolation leaves the others, and nobody can say when the pipeline is good enough.
Who it’s for: A small team whose CI is both slow and unreliable: long waits, jobs killed or hanging, a few tests that fail at random, and a habit of re-running until green.
Usually starts when: People wait on CI all day, a release is coming, or a new hire's first task would otherwise be fighting the pipeline.
The result: You buy the result, not the tickets. The named pipeline meets an agreed duration on the default branch and, over an agreed observation window, none of its runs fails for a cause on the agreed list. Each change comes with evidence, and anything left is named in writing.
How the work fits together
The project is complete when you accept the agreed list: the pipeline meets the agreed duration on the default branch and, over the observation window, no run fails for a cause on the agreed list. Changes that did not apply are removed from the list in writing.
Fix one failing GitHub Actions job and show a green run Job First
One failing job in one workflow runs green on your pull request branch, on the same trigger, with the before and after logs attached. You review and merge the change.
On GitHub Actions, if a job is red first we fix that with this single-job repair, at its listed price, so every change can be checked. On GitLab CI a job that starts and then fails is not covered by a fixed-price outcome; ask for a quote before the project.
Make one CI pipeline's dependency cache hit when dependencies are unchanged Job Included
On a re-run with unchanged dependency files, the named pipeline restores its cache and the install step finishes within the target you agreed. A changed lockfile still rebuilds the cache.
One dependency cache
Make monorepo CI build and test only the packages a change affects Job Optional
For five agreed test changes, only the packages that depend on the change run their jobs, required checks still report, and the default branch still runs everything.
If the repository holds several packages
Make a GitLab CI job that never starts actually run on a merge request Job Each time it fires
The named GitLab CI job starts and finishes on a merge request pipeline on a runner you agreed, after we correct the pipeline rules or tags, or give your admin the exact runner setting to change.
Up to two jobs, if a GitLab job never starts
Applies on GitLab CI only.
Stop one CI job from hanging until the timeout cancels it Job Each time it fires
The named job finishes on its own, within the duration you agreed, on several consecutive runs of the same trigger, without raising its timeout. You receive the cause and the change.
Up to two jobs, if any hang
Stop a CI job being killed for running out of memory or disk space Job Each time it fires
The named job completes on the same runner size with a measured margin left, instead of being killed, with the cause named and no runner upgrade needed unless we tell you and you approve it.
Up to two jobs, if any are killed
Stabilise flaky tests, up to five, priced per test, each one fixed or openly quarantined Job Optional
Up to five named tests that fail at random, priced per test from £395 for one test. Each is reproduced, its cause found, then fixed or, with your approval, quarantined. You get a pull request.
Up to five named tests, each quoted and paid for separately from £395, as in that job
Each test is fixed, or openly quarantined with your written approval, a reason, an owner and a review date, as in that job.
How an engagement works
The price covers the agreed list only. Causes added later, or found by the baseline beyond what the quote assumed, are quoted separately, and a cause that turns out to be a bigger job is re-scoped with you.
How it starts
You send a link to the repository, the pipeline name and what hurts most, and describe or export what your CI history shows, without sharing code.
From that description alone, without access to your repository or CI, we propose a provisional duration target, the causes in scope, an observation window and a price cap.
You agree the list, price cap and terms in writing. Nothing starts, and we have no access to your repository or CI, before then.
After you agree, you share the run history and a repository or fork you control; we measure the baseline and confirm the target. If the baseline shows more causes or a bigger gap than the quote assumed, we stop and show you the evidence, and the price changes only if you agree a new written price.
We work through the list, sending a pull request with evidence for each change.
We run the observation window and send the final summary, then hand over anything left open.
Who decides what
You decide the target and the list and accept each change. Your team merges and deploys on its own gates.
Handover
Each accepted change arrives as a pull request with its evidence. Anything left unfinished is handed back with notes.
Sharing your product safely. Describe the pipeline and its history in words and send no logs, code, tokens or customer data. After you agree the project in writing, share run history and a repository or fork you control, with no production access.
What is included, and what is not
- A pull request for each accepted change, with its before and after evidence
- A table of pipeline durations before and after, with the runner types
- The observation window's run list showing each run's result
- A final summary: accepted, removed, and anything that turned out to need a bigger job
Included
- One repository's pipeline, on one CI system, with a provisional duration target and observation window agreed in writing from what you describe or export, and the target confirmed in writing once the baseline is measured after you agree
- The causes in scope, chosen from slow dependency installs, builds of unaffected packages, hung jobs, jobs killed for memory or disk and up to five named flaky tests
- What the project adds to buying the jobs one by one: a duration target agreed from your run history, a before-and-after table of the whole pipeline's median duration on the same runner types, an observation window of default-branch runs, the changes made in the order that keeps each measurement valid, and one acceptance of the finished list
- A written final summary showing each change and how it ended
- A price cap for the agreed list, stated before any access and never lower than the sum of the listed jobs for the agreed causes
Not included
- Moving to another CI system or restructuring the repository
- Buying runners, plans or paid platform features
- Application defects that the tests correctly report
- Deployments, production changes or repository settings, which stay with your team
- A guarantee of future pipeline duration or reliability beyond the observation window
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The named pipeline's median duration on a clean run of the default branch is at or below the target agreed in writing, measured on the same runner types as the baseline.
Evidence: The before and after duration table with run links.
Over the agreed observation window of default-branch runs, no run fails for a cause on the agreed list.
Evidence: The observation window's run list with each run's result and the cause of any failure.
No check, test or required job was removed or skipped to meet the target, except a flaky test quarantined in the open with your written approval and listed with its reason, owner and review date.
Evidence: The job lists before and after, the reviewed diffs and the quarantine list.
Every item on the agreed list is accepted by you or removed from the list in writing.
Evidence: The final summary, with your acceptance or removal recorded for each item.
Sign-off. You accept each change, or send it back with comments, and then you accept the finished list.
If it fails. A cause we cannot fix is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- The pipeline runs on GitHub Actions or GitLab CI and recent run history is visible to you. On GitLab CI, a job that starts and then fails is not covered by a fixed-price outcome and is quoted separately; the fixed-price causes in scope there are a job that never starts, a cache that never hits, hung jobs, jobs killed for memory or disk, flaky tests and builds of unaffected packages
- The same pipeline can run on branches without deploying or using production secrets
- A person on your side can accept changes and merge pull requests
- A provisional duration target and observation window can be agreed from your description, and confirmed once the baseline is measured
We stop and tell you if
- Most of the time is spent waiting for runners that you cannot add
- The target cannot be met without removing tests or checks you want to keep
- Most failures are real defects in the application rather than pipeline causes
What could go wrong
Every change is a separate pull request that your team merges, so any one can be reverted on its own. If the project stops, accepted changes stay accepted and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The pipeline gets faster because checks or tests were dropped. | No check is removed or skipped to meet the target, except a flaky test quarantined in the open with your written approval and listed with its reason, owner and review date; the reviewer compares job lists before and after. |
| A cause in the list turns out to be several different problems. | We price from your description, read the run history after you agree, name causes that are really bigger jobs and re-scope them with you in writing before work on them. |
| The observation window is too short to show a rare failure. | We state the window's length and what it can and cannot show; it is evidence, not a promise about future runs. |
Each change is reviewed separately from the work that produced it, and you accept every change. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each change and approve repeated runs
- You merge on your own gates
Access we would need
- Read access to run history and pipeline files
- Access to a fork or branch for pull requests
Questions
Do I buy tickets or a result?
A result. You agree a target and a list of causes, and you accept the finished list. How we work through the causes is our job.
What if the target cannot be met?
We say so with the evidence, take the item off the list and adjust the price to match. You are not billed for work that is not accepted.
How is this different from the monthly time-budget service?
This is a one-off project with an end: a target met and a window observed. The monthly service keeps watching afterwards.
What does the project add to buying the jobs one by one?
The jobs fix individual causes. The project adds a duration target agreed from your run history, a before-and-after table of the whole pipeline's median duration on the same runner types, an observation window of default-branch runs, the changes made in an order that keeps each measurement valid, and one acceptance of the finished list. The quote is never lower than the sum of the listed jobs for the agreed causes, and each flaky test is priced as in its own job, from £395 a test. The price is a hypothesis we want to test; it is quoted from what you describe, before we have any access.
Send an enquiry
Send us
- A link to the repository and the name of the pipeline (a link only)
- A paragraph on what hurts most: slowness, random failures, killed or hung jobs
- Roughly how long a typical run takes and how long you would like it to take
- What your CI history shows, described or exported without sharing code: how many runs it holds, which jobs hang or are killed, and the names of the tests that fail at random with redacted failure lines only
- Do not send logs, code, tokens or an access invitation in the first enquiry
Later, once you agree
- Only after you have agreed the scope, price cap and terms in writing: read access to run history and the pipeline files through a route you control, with no production access
- Access to a fork or branch we can open pull requests from
- A named person to accept each change, and approval for repeated branch runs
Your repository, runners and secrets stay yours. We have no access to them before you agree in writing. After that we work on branches or a fork you control through a company-controlled identity, never a personal login, and return pull requests. You approve repeated runs, accept each change and merge.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “pipeline-ci-faster-and-stable-project” as the subject.