Project clear-engineering-backlog · revised 10 October 2026
Project
Clear a defined backlog of bugs and small engineering tasks
Give us a list of bugs and small tasks. We agree the list and a fixed price, then return the whole list as accepted, tested changes.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the list, the price and the terms in writing.
The result you are buying
A backlog of small bugs and chores is too dull to schedule and too long to ignore. Each item is cheap, but the list as a whole drains a team's attention, hides the real priorities and makes every release feel riskier.
Who it’s for: A founder or engineering lead with a known pile of bugs and small tasks that keeps slipping behind the roadmap.
Usually starts when: The list has been there for months, a release or a funding round is coming, or a new engineer's first job would otherwise be tidying it.
The result: You buy the finished list, not the individual tickets. Every agreed item comes back fixed, tested and accepted by you, or is removed from the list in writing.
How the work fits together
The project is complete when every item on the agreed list has been accepted by you or removed from the list in writing. You accept the finished list, not each internal step.
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.
If your CI is red we fix that first, so every change can be checked.
Fix one reproducible bug with a failing-then-passing regression test Job Included
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.
One for each bug on the agreed list
After: Fix one GitHub Actions job
Add one small web-app feature you can try in a private preview Job Optional
Try one agreed feature in a private, time-limited preview of your existing web app. Receive tests, screenshots and two revision rounds before you accept the result.
Small features, if you add them to the list
How an engagement works
The price covers the agreed list only. Items you add later are quoted separately, and items that turn out to be bigger jobs are re-scoped with you.
How it starts
You send a link to the list and tell us which items matter most.
We read the list, try to reproduce the bugs and propose which items are in the project, with a fixed price.
You agree the list, price and terms in writing. Nothing starts before then.
We work through the list, sending a preview or a pull request for each item for you to accept.
We send the final summary and hand over anything left open.
Who decides what
You decide what is on the list and accept each item. Your team merges and deploys on its own gates.
Handover
Each accepted item arrives as a pull request with its test. Anything left unfinished is handed back with notes.
Sharing your product safely. Send a link to the list, never the tickets' contents or any customer data. After you agree the project, invite us to a repository or fork you control and send run instructions and synthetic test data.
What is included, and what is not
- A pull request for each accepted item, with its regression test
- A private preview and screenshots for items that change what users see
- A final summary of the list: accepted, removed, and anything that turned out to need a bigger job
Included
- One agreed list of bugs and small tasks on one product
- Each item fixed or built with a test that would have caught it, and run in a private preview where it changes what a user sees
- A fixed price for the agreed list, set after we have read it
- A written final summary showing each item and how it ended
Not included
- Items added after the price is agreed, unless you add them to the list in writing
- Large features, redesigns, migrations or anything that is really a new project
- Production access, deployments or data, which stay with your team
- A guarantee that every item on a draft list is possible; items that are not are named and removed or re-scoped with you
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every item on the agreed list is either accepted by you or removed from the list in writing.
Evidence: The final summary, with your acceptance or removal recorded for each item.
Each fixed bug has a regression test that fails without the fix and passes with it.
Evidence: The test output before and after, attached to each pull request.
The whole test suite passes with every accepted change applied.
Evidence: A passing run of the full suite on the combined branch.
Sign-off. You accept each item, or send it back with comments, and then you accept the finished list.
If it fails. An item 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
- Each item is described well enough to reproduce or to test, or you can help us do so
- The product can run in isolation with test data that holds no customer information
- A person on your side can accept changes
We stop and tell you if
- Most items cannot be reproduced or tested without production access
- The list is really one big project, so we propose a different scope
- Nobody can accept changes on your side
What could go wrong
Every item is a separate pull request that your team merges, so any one can be reverted on its own. If the project stops, accepted items stay accepted and the rest is handed back with notes.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Items on the list are bigger than they looked. | We read and try to reproduce each item before pricing, name the ones that are really bigger jobs, and re-scope them with you before work starts. |
| Fixing one item breaks another. | Each fix carries a test, the whole suite runs, and an independent review looks for side effects before you see the change. |
| The list changes while we work. | The price covers the agreed list. Additions are written in and quoted, never absorbed silently. |
Each change is reviewed separately from the work that produced it, and you accept every item. 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 item
- You merge and deploy on your own gates
Access we would need
- Read access to a repository or fork you control; no production access
Questions
Do I buy tickets or a result?
A result. You agree a list and a price, and you accept the finished list. How we get through the items is our job.
What if some items cannot be fixed?
We name them with the reason, take them 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 engineering lane?
A project ends when its list is done. The lane continues month after month for a steady stream of work.
Also part of
Start with an email
Send us
- A link to the list of issues or tickets (a link only)
- The items you care most about, in order
- A paragraph on what the product does and how you run it
Later, once you agree
- Read access to a repository or fork you control, with no production access
- Run instructions and synthetic test data
- A named person to accept each item
Your repository and data stay yours. We work on branches or a fork you control and return pull requests. Previews are private to the people you name and end when the project does.
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 “clear-engineering-backlog” as the subject.