What It Is

Prioritizing Time-to-Ship over Efficiency is the strategic decision to favor the speed of delivery and the immediate realization of value over the optimization of resources, code, or processes. In the State Change ecosystem, this isn't a license to be sloppy; it is a fundamental acknowledgment that in the early stages of any feature or product, the most expensive resource you have is not server costs or developer hours—it is time lost to a closed feedback loop.

This mental model shifts the goalpost from "How can we build this the 'right' way?" to "How can we get this into the user's hands the fastest way possible?" It is a direct rejection of the "measure twice, cut once" philosophy in a world where the wood you are cutting is constantly changing shape. Instead of trying to build a perfectly efficient engine on the first try, you build a "good enough" engine that gets the car moving, knowing full well that you will likely swap it out once you know the terrain better.

At its core, this principle relies on the "You Will Build This Again" (YWBTA) mindset. It assumes that your first version is a disposable probe designed to gather data. Therefore, any effort spent making that probe "efficient"—whether that means highly performant code, a perfectly normalized database, or a complex, scalable architecture—is wasted effort if the probe reveals that you’re headed in the wrong direction.

Why It Matters

The primary problem this model solves is the Efficiency Paradox. In software development, especially with no-code/low-code tools or rapid prototyping, developers often get caught in the trap of trying to build for scale or "cleanliness" before they have even validated the core utility of what they are building. This leads to "perfect" systems that solve the wrong problems.

Without this mental model, you fall into the trap of premature optimization. You spend three weeks building a perfectly efficient background processing queue for a feature that, once shipped, you realize your users don't actually need. In this scenario, your "efficiency" was actually a massive source of waste. You were efficient at building the wrong thing.

When you prioritize Time-to-Ship, you unlock the ability to learn. Software is a learning discipline. The faster you ship, the faster you get real-world data. This data is the only thing that can tell you where efficiency actually matters. By shipping quickly, you reduce the "carrying cost" of your ideas. You stop carrying assumptions and start managing facts. It makes it possible to pivot, refine, or even abandon a direction with minimal "sunk cost" guilt because you haven't invested the time required to make it "perfect."

How It Works

This mental model functions as a filter for every technical and tactical decision you make during the development process. It operates through three main mechanisms:

1. The "Good Enough" Threshold Instead of seeking the "best" solution, you seek the "fastest viable" solution. If a "messy" Zapier integration gets a feature live today, while a "clean" custom API integration takes two weeks, you choose the Zapier integration. The "efficiency" of the code or the cost of the subscription is secondary to the speed of the deployment. You are looking for the shortest path between "idea" and "production."

2. Leaving Room for the Rebuild Crucial to this model is the "room for the rebuild." This means you don't build yourself into a corner. While you aren't prioritizing efficiency, you are prioritizing modularity. You build in a way that allows you to rip out the "inefficient" part and replace it later without toppling the entire house of cards. You treat your initial version as a placeholder. This requires enough discipline to keep your "dirty" code or "inefficient" workflows isolated so they don't infect the rest of the system.

3. Intentional Technical Debt You view inefficiency as a form of "high-interest debt" that you are consciously taking on to buy time. You aren't ignoring the debt; you are scheduling it. You ship the inefficient version now to capture the market or the data, with the explicit understanding that once the value is proven, you will go back and optimize. The YWBTA (You Will Build This Again) mantra provides the psychological safety to do this. It gives you the "freedom to prototype more quickly" because you’ve already accepted that the first version isn't the final version.

When to Apply

This mental model is most valuable in high-uncertainty environments. Specifically:

• The MVP Phase: When you are launching a new product or a major new feature set and you don't yet know how users will interact with it.
• Testing New Integrations: When you are connecting to a new third-party API or service. Don't worry about the most efficient webhooks or data syncs initially; just get the data moving.
• Internal Tooling: When building tools for your own team where the "user" is accessible. You can ship something "ugly" and inefficient to solve their immediate pain point today, then refine it as they provide feedback.
• Bottleneck Breaking: When a project is stalled because of a technical debate over the "best" way to do something. Apply this model to break the tie: pick the path that ships the fastest.

It is less applicable when the cost of failure is extremely high (e.g., medical software, core financial transactions) or when you are operating at a scale where "inefficiency" means the system literally won't run. However, for 90% of business logic and feature development, time-to-ship remains the superior metric.

Common Traps

The most dangerous misconception is that Prioritizing Time-to-Ship is an excuse for laziness or low quality.

• Shipping "Broken" vs. "Inefficient": This model does NOT mean shipping things that don't work. It means shipping things that work but aren't optimized. If your app crashes, that's not a "time-to-ship" win; that's a failure. The logic must be sound, even if the implementation is unpolished.
• The "Permanent Prototype": Another trap is shipping the inefficient version and then never rebuilding it. If you stack too many "quick and dirty" versions on top of each other without ever honoring the "rebuild" part of the philosophy, the system eventually collapses under its own weight. You must actually "leave room for the rebuild" and then execute that rebuild when the time is right.
• Ignoring Data Integrity: You can sacrifice code efficiency, but you should rarely sacrifice data integrity. If your "fast" version mangles user data, the "rebuild" will be a nightmare of data migration rather than a simple code refactor.

How It Connects

This mental model is the tactical execution of the You Will Build This Again (YWBTA) philosophy. While YWBTA is the mindset (accepting impermanence), "Prioritize Time-to-Ship" is the action. It is the practical application of that mindset.

It also connects to the concept of Feedback Loops. The faster the Time-to-Ship, the tighter the feedback loop. In the State Change philosophy, the goal of all development is to shorten the distance between a developer's hypothesis ("I think this will work") and the real-world validation ("The user actually did X").

By de-emphasizing efficiency, you are essentially reducing the "friction" in the feedback loop. You are removing the self-imposed barriers (like perfect refactoring or infrastructure scaling) that stand between you and the truth of your product’s value.

Evidence from Sources

On the priority of delivery speed over optimization:

"Don’t worry about efficiency, but rather time-to-ship, leaving room for the rebuild." — You will build this again

On the relationship between YWBTA and speed:

"YWBTA gives you the freedom to prototype more quickly, which lets you ship and move faster." — You will build this again

On the strategic importance of rapid iteration (Inferred from the focus on "rebuild"):

This mental model focuses on the importance of delivering value quickly, even if it means sacrificing some efficiency in the initial stages. Faster iteration and learning are prioritized over perfection. — Description (Source: You will build this again)

In Practice

Scenario 1: The Automated Onboarding Flow

A founder wants to build a complex onboarding flow that tags users in a CRM, sends a custom Slack alert, and generates a personalized PDF.

• The "Efficiency" Trap: Spending two weeks writing a custom Node.js script that handles these tasks via direct API calls to ensure "maximum control" and "lowest latency."
• The Time-to-Ship Approach: Using Zapier or Make.com to string the services together in three hours. It might cost $50/month and take 5 seconds to run instead of 1 second, but it’s live today. The founder can see if users even finish the onboarding before investing in the custom script.

Scenario 2: The Data Dashboard

A team needs a dashboard to track internal KPIs.

• The "Efficiency" Trap: Designing a highly optimized data warehouse with indexed materialized views to ensure the dashboard loads in under 200ms for thousands of concurrent users (of which there are currently only five).
• The Time-to-Ship Approach: Connecting a tool like Glide or Softr directly to a Google Sheet or a simple Airtable base. It’s "inefficient" from a data-processing standpoint, but it’s functional by lunch. The team gets the data they need immediately, and they can rebuild the backend when the spreadsheet starts to lag.

Scenario 3: The New Feature Rollout

An e-commerce site wants to add a "Recommended for You" section.

• The "Efficiency" Trap: Building a machine-learning model and a recommendation engine that updates in real-time based on session cookies.
• The Time-to-Ship Approach: Hard-coding the "top 5 most popular items" for everyone or using a simple "Category Match" logic. It’s not the most efficient or "smartest" recommendation, but it’s shipped in a day. The team can then measure if having any recommendations increases average order value. If it does, they "rebuild" with the smarter engine.