Engineering products lab
Nobody is entirely sure — that is the industry's actual default state. We build the tools, frameworks and solutions that help engineers, teams and businesses survive the stack, and then outgrow it.
01 — Diagnosis
Nobody set out to build something unmaintainable. It accreted. A framework here, a service there, a dependency four levels deep that arrived as somebody else's transitive decision — and then the person who understood it moved on.
The result is an industry running on systems nobody fully holds in their head, documented by artefacts that stopped being true a year ago, estimated by feel and defended by hope.
That is a tooling gap, not a talent problem. So we build tooling.
RuntimeError: stack is now larger than the team maintaining it
at Dependencies.resolve (1,412 resolved · 40 chosen)
at Architecture.explain (author.left(2023))
at Legacy.estimate (gut-feeling.ts:1)
at Docs.read (last-updated: 2023-07-02)
caught by wtfuc.tech
02 — The arsenal
Each one is narrow on purpose. Small, sharp, does the uncomfortable thing nobody wants to do manually — and stays out of the way otherwise.
Know before you upgrade.
Simulate a dependency upgrade before you commit to it. Drop in a manifest and see the breaking changes, CVEs, licence problems and compatibility issues across Node, PHP, Python, Go and Java — free, with no sign-up to start.
Review below, above and beyond the diff.
Code review the way a principal engineer does it — below the diff for bugs and security, above it for architecture and intent, beyond it for what the code actually does in production. For legacy systems it discovers the architecture before it reviews anything.
The invoice your architecture never sends.
Every tool you adopt bills you in engineer-hours, onboarding time and cognitive load — not just dollars. StackTax puts a number on the bill so "let's add a service" stops being a free sentence.
Read the code nobody documented.
Drop it on a codebase whose authors have all left. Get the module map, the hidden coupling, the parts that are load-bearing and the parts that are just scary — before you promise anyone a delivery date.
Your impact, with receipts.
Performance review season should not be an archaeology exercise. ShipLog keeps a running, evidence-linked record of what you actually shipped and why it mattered — written continuously, not reconstructed in a panic.
03 — Operating principles
Not values on a careers page. These are the constraints we actually design against, and you can hold us to them.
A system nobody can hold in their head is not sophisticated, it is unfinished. The hard part was never adding capability — it was deciding what to leave out and defending that decision in a room full of people who wanted their thing in it.
You did not choose most of what you ship. You inherited it four levels deep from a maintainer who stopped answering issues in 2021. That is survivable, but only if you know which promises are still being kept.
Documentation should explain intent, not compensate for a bad interface. Every onboarding doc that exists purely to warn people about a footgun is a design review that never happened.
The instinct to generalise a problem before you have solved it twice is how a two-day task becomes a platform. We build narrow tools that do one uncomfortable thing well, and we resist the abstraction until it earns itself.
04 — Who this is for
The same failure shows up at three altitudes. We build for all of them, because they are the same problem with different budgets.
You inherited it. Now you own it.
Velocity is a property of the system, not the people.
Technical risk is business risk with a longer fuse.