.png)
Work back from the future state
A widely shared space manifesto has a lesson for anyone building healthcare software. It is not about rockets. It is about how you build toward an outcome that does not exist yet.
In June, Marc Andreessen and Michael McGuiness published a manifesto that reads like science fiction with a balance sheet attached. It makes the case for SpaceX as the transport layer for a multiplanetary civilization: launch costs collapsing from tens of thousands of dollars per kilogram toward a hundred data centers in orbit, and at the far end, a mission the authors describe as building a sentient sun.
You can set the cosmic ambition aside. Plenty of readers did. Underneath it is an operating manual, and that manual is the most useful thing in the piece. It is not really about rockets. It is about how you build something genuinely hard, and it maps remarkably well onto the work my teams do every day: building software for the people who deliver care.
The manual fits in one line: Name the future state, then work back from it.
A program reverse-engineered from its endpoint
The tell in the SpaceX story is the order of operations. The program does not start from where rocketry is today and takes the next reasonable step – it fixes an endpoint and derives the entire stack backward from what that endpoint requires.
Cheap launch requires a fully reusable rocket. Building that rocket requires a business capable of funding its development. Each layer exists because the layer above it demands it. The plan runs from the goal back to the present, and every piece has to justify itself against the endpoint or it does not get built.
You can watch that discipline in the single number the whole plan depends on – the cost to lift one kilogram to orbit.
Nobody reached the bottom row by making the space shuttle a little better every year. That number is the endpoint, and the entire vehicle program is what working back from it looks like. The Starship figure is still a projection, but the direction of travel is the point.
The same discipline applies even when the destination is much closer to home.
Our endpoint is not Mars
At WellSky, our future state is not a colony on another planet. It is a health and community care system that actually behaves like one system. A patient leaves the hospital, and the next caregiver already has what they need. A home health nurse spends more of the visit focused on the patient rather than on the keyboard. A care manager has the information needed to see more of the whole person across settings. Less administrative weight on people who chose this work to care for others, not to fight software.
That is a destination, and it does not fully exist yet.
The temptation in any large software organization is to improve the present instead of building toward the future. You take the next locally sensible step, then another, and you end up with a steadily better version of the thing you already have. Working back from a defined future state is what keeps a roadmap pointed at the outcome that matters rather than at the artifact in front of you.
And as building software gets faster, that discipline becomes even more important.
Why the discipline matters more now
For most of the history of software, the cost of writing code was a natural brake on building the wrong thing. That brake is loosening. AI can now help teams generate and iterate on software very quickly, and it can do it toward a destination no one has actually defined.
In many industries, that is merely wasteful. In ours, it is something to take seriously. We build in a regulated, safety-relevant domain where software supports clinical and operational workflows that affect real people. Speed is genuinely welcome, and we are investing in it deliberately. But speed toward an undefined endpoint is exactly the risk to manage.
The answer is not to slow down. It is to be relentless about naming the future state first, so that everything we accelerate is actually aimed. Once that endpoint is fixed, the question becomes how to work back from it.
The algorithm
SpaceX runs a five-step method to reach its endpoint. It maps cleanly onto how strong engineering teams work, and the order is the whole point.
Question every requirement. Make it earn its place, and attach a person's name to it, not a committee. When code is cheap to produce, the requirement becomes the expensive part, and it deserves the hardest scrutiny. A requirement that does not trace to a better experience for a patient or caregiver is the first thing to challenge.
Delete what you can. If you are not adding a little of it back later, you did not cut deep enough. In healthcare software, complexity is not only a cost; it is a surface where risk hides. The most valuable change a team makes in a given week often removes more than it adds.
Simplify, but only after you delete. The classic trap is optimizing something that should not exist. Do not build a polished, well-tested version of a workflow you were about to retire.
Accelerate the cycle. AI has already shortened parts of the build loop, so the bottleneck has moved. It is no longer just typing. It is judgment and verification. Speed up the loop that is actually slow now: the distance between the moment the code runs and the moment you’ve verified it.
Apply AI thoughtfully, and do it last. This is a step teams can easily invert. Applying an AI agent to a clinical or operational process you never questioned, removed, or simplified can simply speed up an inefficient process. In our world, AI comes only after the underlying workflow is understood and validated. It is the final step, not the first.
The underlying principle is simple: Every layer needs to earn its place. And that raises another question — how much complexity are you carrying along the way?
The complexity you carry
The SpaceX teams use a blunt measure they call the idiot index, the ratio of a finished part's cost to the cost of the raw material inside it. A high number means you are paying for process rather than substance.
Software has the same ratio hiding in it. Call it the complexity you carry divided by the value you deliver to a caregiver or a patient. Layers that exist only to serve other layers. A pipeline no single person can explain. AI can push this ratio in the wrong direction because it produces ceremony as fluently as it produces substance.
Part of engineering leadership now is keeping that ratio honest, so the weight we carry stays tied to the value we create. But even a disciplined process and a simpler system do not tell you whether you have actually reached the outcome you set out to achieve. For that, you need reality.
Reality is the only adequate validator
The line from the manifesto I keep returning to is that reality is the only adequate validator. SpaceX flies the rocket to learn whether it works because no review meeting can tell you what a launch can.
In a field where the stakes are someone's health, the artifact is never the proof.
For healthcare software, reality is not a clean demo. It is not a model explaining, fluently, why its output must be correct. It is the clinician's actual day, the patient's actual experience, and the workflow performing safely under real conditions.
The specific temptation of this moment is to accept the artifact in place of the outcome — to let a confident explanation stand in for evidence. We cannot. Results observed in the real world and validated by the people who do the work are what matter. That is why human oversight and clinical validation are not friction in our process. They are essential to the process.
Work back from where we are going
You do not need a rocket, or a sentient sun, to use any of this. Name the future state. Work back from it. Question, delete, simplify, accelerate, and then apply automation, in that order and not another. And let reality, not the demo and not the narrative wrapped around it, tell you whether you actually arrived.
Our future state is a care continuum that behaves like one connected system, in service of the people who give and receive care. Building toward it just became faster and cheaper than it has ever been, which is exactly why the discipline of aiming — of naming the endpoint and cutting everything that does not serve it — matters more than ever.
The tools are new. The job is the same one it has always been: Build toward the outcome, and answer for what you ship
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Joe Baker is Senior Vice President of Software Engineering at WellSky, where his teams build technology for providers across the health and community care continuum.
This piece references “SpaceX & the Sentient Sun” by Marc Andreessen and Michael McGuiness. Views are the author's own. Launch-cost figures are illustrative, as noted above.
