You Will Build This Again (YWBTA)

What It Is

"You Will Build This Again" (YWBTA) is a fundamental shift in how we perceive the lifecycle and "solidity" of software. At its core, this mental model is a mantra that reminds us that software is not a permanent monument carved in stone; it is a temporary construct. It is a snapshot of our current understanding, a reflection of what we know at the specific moment we sit down to write the code.

In Ray’s perspective, the software you are writing right now is a placeholder for the software you will write once you actually understand the problem. It encourages a "disposable" mindset toward implementation details while maintaining a "durable" mindset toward the underlying ideas. Instead of agonizing over a "final" architecture, YWBTA posits that the best path forward will inevitably change as we learn more about the user's needs, the technical constraints, and the market's demands. Therefore, the software must change, too.

Why It Matters

The primary problem YWBTA solves is the "Perfectionism Trap"—the paralyzing fear that every technical decision must be the "correct" one for all eternity. Without this mental model, developers and founders often get stuck in "analysis paralysis," trying to over-optimize for future scenarios that may never happen. They build complex abstractions for scale they haven't reached or features they haven't validated. This leads to slow shipping cycles, bloated codebases, and a high emotional cost when a pivot is finally required.

With YWBTA, the weight of the "perfect decision" is lifted. What becomes possible is a radical increase in velocity. When you accept that the current iteration is temporary, you gain the freedom to make the best decision with the information you have today. You stop treating code as a precious heirloom and start treating it as a tool for discovery. This mindset transforms "rebuilding" from a sign of failure into a natural, expected phase of the development lifecycle. It recognizes that the most expensive part of software isn't the typing; it's the thinking and the learning.

How It Works

The mechanism of YWBTA is rooted in the "Successive Rebuild" framework. It breaks down into three core principles:

1. Software as Knowledge Manifestation: Software is simply the physical (or digital) manifestation of your current mental model of a problem. Because learning is a continuous process, the software must be fluid. If you are learning, your software must be evolving. If your software isn't changing, it usually means you've stopped learning.
2. The Information-Decision Loop: You are tasked with making the best decision with the information you have right now. YWBTA acknowledges that your information is currently incomplete. By building the "first" version, you generate the very data needed to make the "second" version better. Successive rebuilds become easier because you are no longer guessing; you are reacting to reality.
3. Economic De-risking: Re-manifesting an idea "anew" is often cheaper and better than trying to patch an old, misunderstood version. When you build the second time, you aren't starting from zero. You are starting with a map of the territory. The "rebuild" is faster because the cognitive load of "what should this do?" has already been solved in the first iteration.

This model works by prioritizing "speed to insight" over "elegance of implementation" in the early stages. It suggests that the most efficient way to get to a high-quality, permanent solution is to pass through several low-fidelity, temporary solutions.

When to Apply

YWBTA is most valuable in high-uncertainty environments. This includes the early stages of a startup, the "v1" of a new feature, or when experimenting with a new technology stack. Specifically, apply it when:

• The Requirements are Fuzzy: When you aren't 100% sure what the user actually wants, don't build a robust, scalable system. Build a "YWBTA" version to see how they break it.
• Integrating New Tech: If you are using a tool or API for the first time, your first implementation will be amateurish. Accept this. Build it to learn the API’s quirks, then plan to refactor or rebuild it once the "magic" is understood.
• Prototyping Core Logic: When the business logic is complex, YWBTA allows you to "sketch" the logic in code. Once the logic is proven to work, you can rebuild it with proper error handling, logging, and performance optimizations.

Essentially, whenever the "cost of being wrong" is high, but the "cost of not knowing" is higher, YWBTA is the tool to use.

Common Traps

The most dangerous misconception about YWBTA is that it is a license for "sloppy work." It is not an excuse to write unreadable, unmaintainable garbage. The goal is to build the best version possible with current info, not to be lazy. If the code is so poorly written that it doesn't even serve as a learning tool, you've missed the point.

Another trap is the "Permanent Prototype." This happens when a team uses YWBTA to justify a quick hack but then never actually performs the "rebuild." They end up with "v1" running in production for five years, accumulating massive technical debt. YWBTA requires the discipline to actually follow through on the "Again" part of the mantra when the information changes.

Finally, do not confuse YWBTA with "throwing away work." The work isn't the code; the work is the learning. The code is just the evidence of that work. You aren't losing progress when you rebuild; you are consolidating your gains.

How It Connects

YWBTA fits into a broader philosophy of iterative development. It is the ideological foundation for concepts like Technical Debt Management. In this context, technical debt isn't a mistake; it's a deliberate choice to favor current learning over future-proofing. By accepting that "You Will Build This Again," you are essentially taking out a "knowledge loan" that you intend to pay back once the requirements are clearer.

It also connects to the One-Two Rule (building it once to see how it works, and a second time to make it work right). YWBTA provides the psychological safety to execute that rule. It aligns with the idea that the first version of any complex system is always a prototype, whether you admit it or not. By admitting it upfront, you reduce stress and increase the quality of the eventual "final" product.

Evidence from Sources

Software as a Temporary Construct

"“You will build this again” is a mantra that reminds us that software is a temporary construct. It reflects what we know at the time we built it, and as we keep learning more, the best path forward changes, and that means the software does too." — You will build this again

Learning-Driven Evolution

"It reflects what we know at the time we built it, and as we keep learning more, the best path forward changes, and that means the software does too." — You will build this again

Decision Making Under Uncertainty

"Make the best decision with the information you have, because making correct technical decisions becomes easier with successive rebuilds." — You will build this again

The Efficiency of Iteration

"You will build this again means re-manifesting the ideas anew will be cheaper and better each time." — You will build this again

In Practice

Scenario 1: The API Integration

Imagine you are integrating a complex third-party payment processor for the first time. You could spend three weeks reading every edge case in the documentation and trying to build a "perfect" wrapper. Or, applying YWBTA, you spend two days building a "happy path" integration. This integration is "temporary." As you use it, you learn exactly how the API responds to your specific data. You discover which errors actually happen and which are theoretical. Two weeks later, you "build it again" from scratch. This second version takes only three days and is vastly more robust than the "perfect" version you would have spent three weeks on, because it’s based on real-world interaction, not documentation theory.

Scenario 2: The MVP Dashboard

A founder wants a complex data dashboard with 20 different filters. Instead of building a scalable GraphQL backend with complex indexing, the developer applies YWBTA. They build a simple, "brute force" version that pulls all data into the client and filters it there. It’s slow if there are 10,000 rows, but currently, there are only 50. This "temporary construct" allows the founder to show it to users. They realize users only actually care about three of the filters. When the developer "builds it again" for production, they only build the three filters that matter, saving weeks of work on the other 17.

Scenario 3: The Architecture Pivot

A team builds a system using a NoSQL database because it’s fast to set up. As the application grows, they realize the relational nature of their data makes NoSQL a nightmare. Without the YWBTA mindset, the team might feel they've "failed" or try to force the NoSQL DB to work forever to avoid "wasting" the initial work. With YWBTA, they recognize that the NoSQL version was a necessary step to learn the data's true structure. They rebuild the data layer in PostgreSQL, doing it "cheaper and better" because they already know the schema requirements inside and out from their time with the first version.