Make it exist first, make it good later: why starting simple accelerates real products

There is a recurring trap in technical projects: trying to design version three of a system before getting version one to run at all.

On paper, everything looks clean. The team anticipates future scenarios, builds abstractions for problems that have not happened yet, and delays the first release in the name of a supposedly definitive architecture. When the product finally meets real usage, the actual bottleneck turns out to be somewhere else entirely.

The two photographs above capture a methodology I consistently advocate across engineering, product, and technical leadership: make it exist first, make it good later.

The lesson from the Raptor engines: visible complexity before elegant simplicity

The comparison shows two generations of the Raptor engine developed by SpaceX to power the Starship system.

In the first image, Raptor 1 looks like a tangle of external pipes, wiring harnesses, valves, and sensors. From the outside, it might look unfinished. In practice, that layout served a precise purpose: getting a full-flow staged combustion engine onto the test stand, measuring pressure and temperature at every node, and learning how the hardware behaved under real fire.

In the second image, Raptor 3 presents a clean silhouette. Cooling channels and secondary flow paths were integrated into the housing walls, exposed joints were removed, mass dropped, and thrust increased.

The central lesson of that progression is straightforward: you could not design Raptor 3 directly on a blank whiteboard.

Without the external sensors and accessible plumbing of Raptor 1, engineers would not have known which connections could be safely integrated or where thermal margins had to change. The simplicity of the third generation did not come from theoretical guessing; it came from the evidence gathered by making the first generation exist and run.

Make it work, make it right, make it fast

In software engineering, Kent Beck distilled this sequence into the classic iterative principle: “Make it work, make it right, make it fast”.

When teams invert that order, they pay a steep price on two fronts:

1. Paralysis at the starting line: months go into debating the ideal structure while users and operations receive nothing.
2. Blind optimization: the team hardens parts of the system that will need to change in the first week of real usage, while leaving the actual pressure points under-protected.

Martin Fowler addresses this directly when writing about sacrificial architecture: accepting that the first version of a system exists to prove value and reveal what the next version will genuinely need to handle.

This aligns with Gall’s Law, formulated by John Gall in Systemantics: a complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch rarely works on first contact with reality.

How this applies to products and AI systems in production

Building software products and applied AI systems brings this contrast into focus every day.

Faced with an operational problem, the initial impulse in many teams is to design an elaborate mesh of autonomous agents, dozens of tool integrations, and complex orchestration before validating a single assisted decision.

Applying the discipline of starting first and improving later changes the path:

• Start with a narrow, observable workflow: pick one concrete operational step (such as enriching alert triage or organizing vulnerability evidence) and put it to work within a bounded scope.
• Keep the “instrumentation exposed” in version 1: just like the visible pipes and sensors on Raptor 1, the first version of an AI workflow needs to log inputs, retrieved sources, generated recommendations, and human edits. Without seeing where the model hesitates or fails, every attempt to refine the system is guesswork.
• Simplify based on real telemetry: after weeks in operation, it becomes clear which steps deliver value, which prompts or tools create noise, and where automation can safely advance. Only then does it make sense to consolidate the architecture and strip away extra layers.

Making it exist first does not mean shipping carelessly

Pragmatism is not carelessness. Putting a first version into the world does not mean cutting corners on security, privacy, or reliability.

On a rocket test stand, the prototype may have exposed plumbing, but it runs inside strict containment and dense telemetry. In software and AI, the same principle holds.

For a first version to exist safely and teach the team what to improve, three foundations are non-negotiable from day one:

• Clear data and access boundaries: least privilege for integrations, protection for sensitive data, and environment isolation.
• Humans in the loop for high-impact decisions: while the system matures, consequential actions require explicit human review.
• The ability to measure and roll back: if behavior drifts from expectations, the team must spot it quickly and revert without disrupting operations.

With those guardrails in place, the rest of the product is free to start simple, learn quickly, and evolve on evidence.

Making it good later is part of the commitment

The phrase only works when both halves stay connected. “Make it exist first” breaks inertia; “make it good later” takes the discipline to revisit what was built, remove excess complexity, and turn operational learning into durability.

Before delaying the next release or polishing a diagram that has never met production, four questions help clarify the next step:

1. What is the smallest version of this system that solves a real problem safely?
2. What signals do we need to measure in version one to know what to change in version two?
3. What are we trying to settle on a whiteboard that only real usage can answer?
4. When will we schedule the work to turn the working prototype into the lean architecture that lasts?

Technical excellence rarely arrives fully formed in the first draft. More often, it is the visible result of having the courage to make it exist first and the discipline to make it good later.

Which project or improvement are you trying to design as “version 3” on paper right now, when the real breakthrough is getting “version 1” running?