Perth, Western Australia
A deploy should be one reviewed script.
Scriptshift builds release tooling for software teams of two to five people. The working rule is short. If a deployment cannot be read start to finish by somebody who did not write it, we do not count it as a deployment. We count it as a habit that has not failed yet.
- Registered
- 2026
- Published products
- None
- Customers
- None
- Outside funding
- None
Working rule
1One artefact a second person can read
Everything a release needs lives in one committed file that sits in the repository beside the code it ships.
A deployment is a sequence of decisions about what to change, in what order, and what to do when a step does not come back. In a small team that sequence usually lives in three places at once. Part of it is a wiki page written during the last incident. Part of it is a chat message somebody starred. The rest is in the head of whoever set the thing up in the first place.
Each of those degrades in its own way. The wiki page goes stale the first time a flag is renamed and nobody thinks to edit it. The chat message scrolls out of reach. The person who remembers the rest takes annual leave in the same week a certificate expires.
Our position is that the sequence belongs in a single executable file, committed alongside the application, changed through the same review process as the application, with no step that exists only as an instruction to a human. That is the whole idea. Everything else on this site is a consequence of it.
What readable means here
Readable is not a feeling. We hold a release file to five properties, and every one of them is something a reviewer can check without running anything.
The fifth property is what makes the other four testable. A file that can describe itself is a file a reviewer can disagree with before it runs, which is the only moment when disagreement is cheap.
Status
2What exists today
Internal tooling, used on our own repositories. Nothing is published, nothing is downloadable and nothing is for sale.
A status section belongs near the top of a page rather than in a footnote at the bottom of one. The company was registered in 2026. It has published no product, has no customers, has taken no outside investment and has earned no revenue. The tooling below runs inside the company and nowhere else.
None of this has run outside our own repositories. It has not been tested against a deployment we did not write, on infrastructure we do not control, or by a team that did not build it. Those three conditions decide whether any of it turns out to be useful, and all three of them are untested.
Non-goals
3What it does not do
The list of non-goals is longer than the list of features, and it is the more useful of the two.
- No agent. Nothing is installed on your servers and nothing runs in the background. The tooling is a command that runs where you already run your build.
- No hosted control plane. There is no dashboard, no account and no service to sign into. Removing us from the picture means deleting a file from a repository.
- No secret storage. Secrets stay in whichever manager you already use. The tooling names what it needs and refuses to start when one is absent, and that is the whole of its involvement with secrets.
- No infrastructure provisioning. Terraform, OpenTofu and Pulumi exist and are good at this. A release file calls them. It does not replace them.
- No promise above roughly ten engineers. Past that size the coordination problem changes shape, and the honest answer is a different product built by somebody who has worked on it.
- No compliance claim. Nothing here is offered as evidence towards an audit, a framework or a certification, and a review gate that produces a record is not the same thing as a control.
A non-goal that is written down is a commitment. A non-goal that lives in somebody's judgement is a preference, and preferences move the first time a large enough customer asks.
Scope
4Why teams of two to five
At that size nobody is a release engineer, and the person who wrote the change is the person who ships it.
The failure we care about is not a bad process. It is the absence of any process that survives one person being unavailable. A team of four does not need a change advisory board and would not tolerate one. What it needs is for the second person to be able to read what the first person is about to do, in the ten minutes before they do it.
Every design decision follows from those ten minutes. A dashboard does not help, because the reviewer is already looking at a pull request. A domain specific language does not help, because it adds something to learn before the reviewer is allowed to disagree. Anything that makes the file longer than a person will genuinely read is a defect, even when it is technically correct.
The two person property
We keep coming back to one test. Hand the release file to the colleague least involved in the change. If they can say what will happen, in what order, and what will be true afterwards, the file is finished. If they can only say that it looks fine, it is not.
Where the reasoning stops
We have not tested this at any other size and we are not claiming that it generalises. A team of forty has a different problem. A regulated environment has a different problem again. Neither is one we have worked on, and neither is one we will pretend to have an answer for in order to widen the market.
Register
5The verifiable part
Everything on this site that can be checked against a public register, and the things that cannot be checked because they do not exist.
SCRIPTSHIFT TECHNOLOGIES PTY LTD does not hold ISO/IEC 27001 certification, a SOC 2 Type I or Type II report, an IRAP assessment, Essential Eight attestation or any other independent accreditation, and will not represent otherwise until one is genuinely held.
There are no customers to name, no case studies, no testimonials, no download figures, no awards, no partnerships and no press coverage. A wall of logos would have taken less time to produce than this paragraph, and it would have been false.
Contact
6One address
Every route into this company is a single mailbox, and it is read by the people who build the thing.
Write to hello@scriptshift.cc. There is no contact form on this site. A form either posts nowhere, which is dishonest, or posts somewhere and quietly collects an address and a set of browser characteristics that nobody asked you for.
Ordinary correspondence gets a substantive reply within 5 business days. A privacy request under the Privacy Act 1988 (Cth) gets 30 days, which is the period Australian Privacy Principles 12 and 13 allow. A suspected security problem gets the same or the next business day.