just-barely-possible — quality + safety report

---
name: just-barely-possible
description: Force ambition calibration to the edge-of-physics limit when the user is doing performance engineering, weight or cost-critical design, spec setting, or staring at a problem that "seems impossible." Triggers on phrases like "this is impossible", "is this even feasible", "the industry says X is the floor", "let's just buy the standard part", "good enough for now", "we'll optimize later", "the constraint is too hard", "let's set a safer target", and any moment a team is pricing ambition by analogy to incumbents instead of by physics. The framework: if a goal does not break a law of physics, it is possible — and on hard problems you must design to "just barely possible" because softer margins guarantee failure. Reusable rockets, 10,000x improvements, catching a booster on launch-tower arms. Strip what isn't load-bearing, run everything close to the edge, and establish possibility first, then probability. Trigger eagerly even when the user does not name Musk or the framework.
---

# Just Barely Possible

> "Nobody thought this was possible. But we're not breaking any laws of physics, so we knew it was possible."
> — Elon Musk, *The Book of Elon* (Chapter: Building the Just Barely Possible)

## What this skill captures

Most engineering targets are set by analogy — what the incumbent did, what the vendor charges, what last year's spec was. That's how you get a space shuttle that costs more per flight than the expendable rocket it replaced. Musk's discipline is the opposite: identify the physical floor, accept that you must operate within a hair of it, and design the system there. "On Earth, fucking hard. Just barely possible." The interesting problems live in the thin band between "impossible" and "comfortable." Anything comfortable is leaving 10,000x on the table.

The value: you stop accepting industry-standard margins as fate, stop padding specs to feel safe, and start picking targets from physics instead of precedent. You force the question "is this even possible?" before "is this convenient?" — and when the answer is yes-but-barely, you commit anyway.

## When to use this skill

- Setting a performance, weight, cost, or latency target and the team is anchoring on the incumbent's number.
- Someone says "this is impossible" or "no one has ever done this" without naming the physical law that forbids it.
- A spec has comfortable headroom and the project is also losing on cost, mass, or speed.
- Designing a critical subsystem (engine, battery pack, hot loop, scheduler) where every gram, watt, or microsecond compounds.
- Choosing between an evolutionary improvement and a revolutionary redesign — and people are defaulting to evolutionary.
- The plan has multiple "we'll optimize later" placeholders that together blow the budget.

## The how-to

1. **Ask whether physics forbids it. If not, it is possible.**
   > "I was told many times rocket reusability was impossible."
   > — *The Book of Elon*
   "Impossible" almost never means physically impossible. It usually means "nobody has done it" or "it would be hard." Those are different categories. Separate them out loud before you accept a no.

2. **Establish possibility first, probability second. Do not collapse them.**
   > "The first step is to establish that something is possible, then the probability it will occur."
   > — *The Book of Elon*
   Teams kill ambitious goals by multiplying "is it possible?" by "will we pull it off?" and getting a small number. Decouple the two questions. If it's possible, commit; then attack probability.

3. **Think in the limit of physics, not the limit of precedent.**
   > "Again here, we try to think in the limit of physics."
   > — *The Book of Elon*
   The booster-catch tower came from asking "what's the fastest possible reuse?" — not "how do we improve landing legs?" Set the target by working backward from the physical floor, then design toward it.

4. **Strip every part that isn't load-bearing to the key problem.**
   > "Eliminate what isn't necessary to solve the key problem."
   > — *The Book of Elon*
   Early Starships had no doors. Doors weren't necessary to get to orbit. Every gram you carry that doesn't pay for itself is mass you stole from payload. Audit the design and delete anything that isn't earning its keep.

5. **Run everything close to the edge — that's the only way the math works.**
   > "To get a lot of payload to orbit at low cost, you have to run everything close to the edge."
   > — *The Book of Elon*
   Comfortable margins on every subsystem compound into an uncompetitive system. The just-barely-possible posture distributes risk across many tight components instead of one slack one.

6. **Reject single-example proofs that something can't work.**
   > "For a long time, people pointed to the space shuttle as an example of why attempting reusability was dumb. But you can't take a single example and make an entire theory out of it."
   > — *The Book of Elon*
   One failed prior attempt is not a physics result. Re-derive the floor yourself before inheriting someone else's conclusion.

7. **Quantify how far from the limit you actually are. Aim for orders-of-magnitude, not percentages.**
   > "Not a 10,000 percent increase, a 10,000-times increase."
   > — *The Book of Elon*
   Mars-cargo cost needs ~10,000x improvement, not 10%. When you're orders of magnitude off the floor, incremental targets are a category error. Pick the order-of-magnitude goal and design for it.

## Common failure modes

- **Anchoring on the incumbent.** "Rockets have always cost X." That's a price, not a physical limit. Recompute from raw materials and propellant.
- **Letting "no one has ever done it" close the conversation.** Musk: full reusability had never been a possible outcome in any prior design. That's because nobody designed for it, not because it was forbidden.
- **Padding the spec to feel safe.** Comfortable margins everywhere = an uncompetitive product. The just-barely-possible posture is uncomfortable on purpose.
- **Confusing "possible" with "easy."** "Just barely possible" still requires brutal execution. The skill doesn't grant the win; it makes the win legal.
- **Optimizing the wrong layer.** Iterating on landing legs when the answer was "delete the legs and catch it on the tower." Always re-ask "what's the physical floor?" before optimizing the current design.

## When NOT to use this skill

- Human lives are aboard and a single failure is catastrophic. Crewed missions need margin; "edge of physics" is for unmanned iteration.
- A working, profitable system where the constraint is distribution or demand, not physics. Don't shave a part that's already pulling its weight.
- The downside of failure is irreversible at the company level (regulatory, legal, safety-of-life). Save the just-barely-possible move for places where you can blow it up and try again.
- The task is genuinely a polish/maintenance pass on something already near its limit. Diminishing returns are real.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Building the Just Barely Possible" (in "Building SpaceX").