Job upgrade-dependency-and-runtime-inventory-with-plan · revised 11 October 2026
Get a tested, ranked upgrade plan for one app's runtime and dependencies
One repository: every runtime, framework and direct dependency checked against the vendor's published support dates, the existing tests run as a baseline, and a ranked upgrade path.
You might be seeing
- Nobody can list which parts of the app are past their vendor's support dates
- Upgrade estimates vary wildly because nobody has run the tests on the current versions
- A host or tool warns about old versions but does not say what to do first
No passwords, keys, card details or admin invites needed to start.
What usually happened
Nobody can say which parts of the app are out of support, which upgrade has to come first or how large each step is. Upgrades then get chosen from a host's warning email or a scanner's red badge, and the order is often wrong: a framework step that needs a newer runtime, or a runtime step that one pinned dependency blocks. The first real cost is the time spent finding that out halfway through a change.
Who it’s for: A founder or engineering lead who knows the app is behind on versions but cannot say what is out of support, what must change first or how big each change is.
Usually starts when: A host warns that a runtime version is being retired, a scanner or customer questionnaire flags old components, or a new engineer asks why the app is still on versions the vendors no longer support.
The result: A written inventory of the runtime, framework and every direct dependency in one repository, each with its current version, the vendor's published support status and the result of running the existing tests, followed by a ranked upgrade path where each step names what changes, what must be tested and how large it is.
Check whether this job fits
Five short questions. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Read the runtime versions on a developer machine
Ask whoever works on the app to run the commands for your stack inside a copy of the project folder and send back only the version numbers.
node --version; ruby --version; python3 --version; php --versionLook for: The version for the runtime your app uses. Ignore the others. Your host's settings page may show a different version from a developer's machine: send both.
Count the direct dependencies
Open the manifest (package.json, Gemfile, requirements.txt, pyproject.toml or composer.json) and count the entries listed under dependencies and development dependencies.
Look for: A number, not the list. The fixed price covers up to 150.
What you get
- The inventory as a spreadsheet file and a readable summary
- The baseline test result, including anything that could not be run
- The ranked path, with every step written up as a separate piece of work and what could block it
- A one-page summary for the person who decides what to buy next
Included
- One repository holding one application, one language runtime and one lockfile
- Up to 150 direct dependencies, meaning the entries in the manifest rather than the whole transitive tree
- For the runtime, the framework and each direct dependency: current version, newest version in the same major line, newest major version, and the vendor's published support status with a link and the date we checked it, or a plain statement that the vendor publishes no date
- A run of the existing test suite on the current versions, recorded as the baseline: passing, failing with the failing test names, or unable to run with the reason
- A ranked upgrade path in which each step lists what must come before it, the checks it needs and a size band of small, medium or large
Not included
- Changing any version in your code or lockfile, which is a separate job for each step
- A security audit, penetration test or compliance review of any kind
- Reviewing the whole transitive dependency tree beyond naming packages that block a step
- A fixed price for later steps: sizes are bands and each step is quoted when you choose it
- Operating-system, database-server or host work beyond recording the versions you give us
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every direct dependency in the manifest appears in the inventory exactly once, with its current version, newest version in the same major line and newest major version
Evidence: The inventory file, where the row count matches a count of the manifest entries
Every row, whether a runtime, a framework or a direct dependency, shows the vendor's published support status with a link to the vendor's own page and the date it was checked, or says plainly that the vendor publishes no date
Evidence: The support columns of the inventory, each with a working link or the plain statement that no date is published
The baseline is recorded as passing tests, failing tests listed by name, or unable to run with the reason
Evidence: The test output from the isolated copy, attached to the plan
Every step in the ranked path names what changes, the checks it needs, a size band and any step that must come first, so a reader can follow any step back to one with no prerequisite
Evidence: The ranked path, reviewed by the independent reviewer for loops and missing prerequisites
Sign-off. You review the inventory and the ranked path and tell us if a dependency or flow is missing. The plan is accepted when your maintainer agrees that it matches what they know of the app. Accepting the plan does not commit you to buy any upgrade.
If it fails. If the inventory is incomplete or a support date has no source, we correct it at no charge. If you do not accept it after one round of corrections, you do not pay and you keep what we found.
When it fits, and when we stop
It fits when
- The stack is Node.js, Ruby, Python or PHP with a lockfile in the repository
- You own the repository or are authorised to share a copy of it
- The tests can be run on an isolated copy without production data, or you agree that the plan will say a baseline could not be established
- Someone on your side can say what the app does and which three flows matter most
We stop and tell you if
- The repository holds several applications or more than one language ecosystem, so each needs its own scope
- There is no lockfile and no way to learn which versions are deployed
- The code is encoded or obfuscated, or cannot legally be shared with us
- The tests can only run against regulated or customer data
What could go wrong
Nothing in your repository or hosting changes, so there is nothing to roll back. When you sign off we delete our copy of the repository and any test environment we built, and tell you in writing when that is done.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A vendor changes a support date after we record it | Every date carries its source link and the day we checked it, and the plan tells you to re-check before you act on it. |
| The baseline test run fails for reasons unrelated to versions | We record the failure as the baseline instead of fixing it, so later steps can be judged against it. |
| A size band turns out too small once the work starts | Bands are ranges with their assumptions written down, and each step is scoped and quoted again with its own checks before you commit. |
A second reviewer checks every support date against the vendor's own page and re-reads the step order for hidden dependencies. A person on your side confirms that the named business flows are the ones that matter.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Restore a read-only copy with secrets removed in an isolated environment and record the runtime and package-manager versions it needs
- Read the manifest and lockfile and list the runtime, framework and every direct dependency with current, same-major-line latest and latest-major versions
- Look up each vendor's published support dates on its own pages and record the link and the day we checked it
- Run the existing tests on the current versions and record the baseline, including what cannot run
- Work out which steps depend on which, for example a framework step that needs a newer runtime, then rank them with size bands and the checks each needs
- Independent review of the support dates and the ordering, then hand over the inventory, baseline and plan
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly service that keeps the runtime and dependencies on supported versions and re-checks these dates.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
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
- Package managers and hosts can already report outdated versions and known advisories. For example, npm's audit command reports advisories for a project's dependency tree. Those lists show what is old, not which upgrade must come first or how to test it. docs.npmjs.com
- GitHub's Dependabot opens pull requests for newer versions. Its documentation says you review the notes and merge yourself, and you confirm that your tests pass. It does not rank a multi-step upgrade. docs.github.com
Questions
Is this a security audit?
No. It records the support status that vendors publish. It does not list security advisories, and it is not a security review, a certification or a compliance check. Clearing advisories is a separate job.
Will you change my code?
No. This job produces a plan. Each upgrade in it is a separate job with its own price and acceptance checks.
Do you need to run the app with my real data?
No. We use a copy with secrets removed and run only your existing tests.
Send an enquiry
Send us
- The language, framework and runtime versions as best you know them
- The names of the manifest and lockfile (not their contents) and, for a public repository, its link
- Why you want the plan now: a host notice, a scanner report, a planned feature or a hand-over
- The three business flows that matter most
Later, once you agree
- A read-only copy of the repository with secrets removed, through the agreed company-controlled secure handoff
- How to run the tests, plus synthetic fixtures if they need data
- The runtime versions your host actually runs, taken from the host's own settings page
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the repository, hosting, accounts and every secret. We work from a read-only copy with secrets removed, in an isolated environment with no production data. A second reviewer checks each support date against the vendor's own page before the plan is handed over. We never ask for passwords in the first enquiry.
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 “upgrade-dependency-and-runtime-inventory-with-plan” as the subject.