Job fix-one-bug-with-regression-test · revised 9 October 2026
Fix one reproducible bug with a failing-then-passing regression test
One reproducible bug in one codebase: a regression test fails before the fix and passes after it. You get the repair pull request and both test results to review.
You might be seeing
- The same input or action sequence produces a wrong value, exception or incorrect application state
- There is no regression test that fails for this specific behaviour on the current code
No passwords, keys, card details or admin invites needed to start.
What usually happened
One reproducible application behaviour disagrees with the expected result. A patch alone would not show whether it addresses that failure or whether it returns later. The job needs a regression test that exposes the agreed defect on the unfixed revision and passes after the repair.
Who it’s for: A founder or CTO with one application defect they can describe and reproduce without production data, who wants the fix protected by a repeatable test.
Usually starts when: A known sequence of actions or inputs produces the wrong result in an existing application, and the team wants that specific failure fixed rather than another untested patch.
The result: The agreed reproduction behaves correctly, and its new regression test fails on the unfixed code and passes on the repaired code. You receive one pull request containing the test, the fix and the evidence to review and accept it.
Check whether this job fits
Describe the behaviour, not your code or customer data. These checks establish whether one safe reproduction and one regression test can define the repair.
Checks you can run yourself
Write a reproduction without private data
From an existing test or an already observed failure, list the starting state, actions, invented inputs, expected output and actual output. Do not reproduce it on production for this check.
Look for: One repeatable wrong result that can be asserted. Separate it from unrelated errors and name any environment assumptions.
What you get
- A reproduction note describing the input, starting state, expected result and observed defect
- A pull request containing the regression test and the bounded code fix
- Failing test output against the unfixed revision, passing output against the repaired revision and results of the agreed nearby checks
- The cause, changed-file list, known limits and code-reversal instructions
Included
- One described bug in one codebase at an agreed source revision, with one expected result
- A bounded reproduction investigation using the agreed reproduction steps, one isolated environment and one synthetic fixture set
- Write and run a failing regression test before changing the application behaviour
- Make the smallest fix, run the regression and agreed nearby tests, then hand back the pull request with the test evidence
Not included
- Performance work, profiling, load testing or a speed guarantee
- Bugs that need production data, production access or credentials to reproduce
- Vague or intermittent reports such as 'it sometimes breaks' without a reliable reproduction
- Multiple bugs: each has its own reproduction, agreement and job
- Security vulnerabilities that require disclosure or incident handling
- A whole-codebase audit, rewrite, CI repair or production deployment
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The new regression test fails against the named unfixed revision with the assertion that matches the agreed bug, not an environment or setup failure.
Evidence: The unfixed source revision, regression-test version, command, synthetic fixture description and captured assertion failure.
The same regression test passes against the repaired revision, and the original reproduction now produces the expected result with the same synthetic inputs.
Evidence: The repaired source revision and passing output from the same test command, plus the before and after behavioural result.
The agreed nearby tests pass, and the pull request contains only this bug's repair, regression test and necessary test support without weakened assertions.
Evidence: Nearby test command results, changed-file list and independently reviewed diff against the agreed baseline.
Sign-off. You inspect the reproduction and failing-then-passing test evidence, review the pull request and accept the agreed repaired behaviour in writing before payment. Your team keeps the decision to merge and deploy; acceptance does not require us to change production.
If it fails. If the bounded investigation cannot reproduce the bug, we return the findings and stop at no charge. If the agreed repair checks fail, you do not pay for that repair. Another symptom, investigation route or larger fix needs a new written agreement before work continues.
When it fits, and when we stop
It fits when
- You can state the expected and actual result for one input or action sequence, with a safe way to repeat it
- The relevant source revision can run in isolation with synthetic fixtures and no production credentials
- The codebase has a runnable test harness in which this behaviour can be asserted, or a small isolated test can be added without a wider test-suite project
- You control the code or have written authority to request a change, and can review and merge the returned pull request
We stop and tell you if
- The agreed reproduction checks do not produce the defect in the named environment with the synthetic fixture set
- A failing test cannot distinguish the reported defect from unrelated environment or test-harness errors
- Reproduction requires production data or credentials, or reveals a security issue needing disclosure handling
- The investigation reveals multiple defects or a larger architecture change: we stop and ask whether to quote a different scope
What could go wrong
Keep the unfixed revision and the failing regression result in the handover. Closing the pull request changes nothing on your default branch. If you merge and later need to reverse the repair, your maintainer reverts the named code change and chooses whether to keep the regression as a failing check. No database or production-data change is included.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| The new test passes on the old code and never detects the defect. | Run the regression against the named unfixed revision first and record the assertion failure. A setup error or passing baseline is not adequate evidence. |
| The patch fixes the reported path but breaks behaviour next to it. | Agree nearby regression checks before the fix, run them after it and list any untested paths or limitations in the handover. |
| A convenient reproduction contains customer records or production secrets. | Use synthetic fixtures and an isolated environment. Stop rather than accept private production inputs when those are needed to reproduce it. |
An independent reviewer checks the behavioural contract and both test results, including that the failure on the old revision is the reported bug rather than setup noise. Your authorised maintainer reviews and decides whether to merge or deploy; we do not replace that approval.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Have your existing maintainer write a regression test that fails for this reproduction before changing the code. If the defect is in a dependency, a minimal synthetic reproduction may also let its maintainer diagnose it. gist.github.com
- If you have a queue of bugs and changes rather than one defect, compare a development subscription. Unlimited Dev's Web plan advertises GBP 995 per month with bug fixes included; confirm its scope and acceptance terms before subscribing. www.unlimiteddev.io
Questions
What if you cannot reproduce it?
We agree the source revision, one setup attempt, environment, synthetic fixtures and reproduction checks first. If those checks do not show the defect, we explain the findings and stop at no charge. We do not turn it into an open-ended investigation.
Why write the test before the fix?
Its failure on the old code shows it detects this particular bug. Its pass on the repaired code then gives you a check you can run when the code changes again. It is not a promise that no other bug exists.
Is £295 the price for any bug?
No. It is the starting price. We reproduce the one agreed bug and confirm a fixed repair quote before changing application code. You can decline that quote.
Will you inspect production or deploy the patch?
No. This scope uses an isolated copy and synthetic data. You review, merge and deploy through your own process.
Start with an email
Send us
- A plain description of one bug: the actions or inputs, expected result and actual result; use invented values rather than customer examples
- The application language and framework versions, affected screen or operation, and whether the defect repeats reliably
- Whether a test harness and synthetic reproduction already exist, described without attaching source code
- Do not send credentials, code, private repository access, production dumps or customer data in the first enquiry
Later, once you agree
- The agreed source revision through a company-controlled repository or code-export route, with a branch route for returning the pull request
- Run and test instructions, the agreed reproduction steps and synthetic fixtures that hold no customer information
- The written reproduction boundary, expected result, regression and nearby test commands, and the person authorised to accept the repair
You keep the repository, accounts, customer data and production keys. We work on the authorised source revision in an isolated workspace with synthetic fixtures through a company-controlled identity, never a personal login. You review, merge and deploy under your own gates. We need no production data or credentials for this job.
This writes an email to us with your request filled in; it reaches us when you send it. Or write to hello@syntheticindustry.ai with “fix-one-bug-with-regression-test” as the subject.