The Startup Wait Calculation

For years, space thinkers have wrestled with a strange problem in interstellar travel: what if the mission you launch today is overtaken by the mission you launch later?

Take Proxima Centauri, the nearest star to our solar system, about 4.24 light-years away.

Say we finally build a spacecraft that can travel at 10% of the speed of light. We launch it today. The trip would take about 42.4 years.

Now imagine that, 5 years later, propulsion technology improves and suddenly we can travel at 20% of the speed of light. A second mission leaves then. It only takes about 21.2 years to get there. In other words, the mission that left later arrives roughly 16.2 years earlier than the mission that left first. When the first mission arrives, they will find that others have not only arrived earlier, but have already been there for a whole 16 years.

That is not just a space problem anymore.

It is becoming a startup problem.

We are entering an era where a founder can start earlier, work harder, spend more, and still get overtaken by someone who starts later with better tools, better agents, and a better way of building.

The later founder does not just move faster. They may actually arrive first.

The stack is aging while we build on it

This is what makes building right now feel so strange.

You pick a stack. You commit. You start building. And halfway through, the world changes.

A tool that felt magical three months ago now feels limited. A workflow that felt smart now feels clunky. Something that looked like core infrastructure turns out to be temporary scaffolding.

Take Replit as one example. If you started early, you were often effectively building a web app first. If you later wanted a native mobile app, that could mean creating a separate project, with a separate frontend and UI, which means more time, more effort, and more AI usage costs. But newer projects now support multi-artifact builds, where web and native mobile apps can increasingly live inside the same project. The founder who started later may simply inherit a cleaner path.

Or take n8n. For a while, tools like n8n felt like the backbone of AI automation. And they still matter. But the point is that what once felt like the obvious long-term layer can quickly become just one temporary layer in a much larger and faster-moving agentic system.

Look at app builders more broadly. Some AI product builders still trap founders in a web-first logic. If your product later needs a proper native mobile experience, deeper device integration, or app-store-grade behavior, an early tool choice can suddenly become a strategic constraint rather than a productivity boost. What felt like speed at the beginning turns into rework later.

Look at coding workflows too. Not long ago, the model was simple: one developer, one AI assistant, one code stream. Now the frontier is shifting toward parallel agent workflows, isolated worktrees, and AI systems that can handle multiple threads of execution at once. That changes not just productivity, but the shape of the development process itself. A founder who builds around yesterday’s coding workflow may end up redesigning their entire operating model, not just their codebase.

Even the concept of “the product” is becoming unstable. In the past, founders built software as a relatively fixed application. Now products can increasingly behave like living systems: web app, mobile app, agents, workflows, copilots, internal tools, API layers, and dynamic interfaces all woven together. If you chose tools assuming you were building one static surface, you may wake up later and realize the market now expects an adaptive system instead.

You realize you did not just build a product.

You built on top of a moment in time.

And in AI, moments expire fast.

This is why the AI startup scene feels so disorienting right now.

It is not just that tools are improving. It is that the architecture of how products get built is being replaced while founders are still building.

The result is a new phenomenon: the startup wait calculation.

Build too early, and you may spend months wiring together what the next tool generation gives your competitors by default.

Choose the wrong abstraction, and your startup does not just move slower. It may be forced to rebuild its product surface, development workflow, or operating model from scratch.

That is why this era feels so exhausting. It is not just that the tools are improving. It is that the assumptions behind how we build products are changing while we are still building them.

The playbook is aging too

The deeper shift is not just about tools.

It is about methodology.

For years, startup people have repeated the same gospel: Build an MVP → Run sprints → Ship small → Stay agile → Follow the roadmap → Groom the backlog → Iterate. That all made sense in a world where software development was mostly about coordinating humans over time.

Humans designed. Humans coded. Humans tested. Humans waited on other humans. So we invented systems to keep all that moving: Agile, scrum, sprints, roadmaps, ceremonies, planning cycles.

None of that was stupid.

It was just designed for a slower world.

Now agents can design, code, test, refactor, document, and explore alternatives in parallel.

So what exactly is a sprint in a world where your product can materially change in a few hours?

What is “agile” when the point of agile was to make slow teams more flexible?

And what is an MVP when you can generate three versions of the product before the first planning meeting is over?

Agile is not wrong.

It is just too human for what is coming.

We need a new way to build

I do not think founders just need better tools.

I think they need a new philosophy of product development.

Something post-agile.

Something built for a world where agents work in parallel, prototypes are abundant, and iteration is almost free.

Call it:

Lightspeed Product Development (LPD)

The core idea is simple:

Stop optimizing around the cost of building. Start optimizing around the speed of learning.

That changes the questions.

Instead of asking, what is the minimum viable product we can build?
Ask, what is the minimum reality we need to validate?

Maybe that is a concierge workflow, a narrow agent experience, or one tiny moment that proves users actually care.

The goal is no longer to build less. The goal is to discover truth faster.

LPD also assumes you should not think so linearly anymore. The old sequence — research, spec, design, build, test, improve — starts to feel outdated when agents can help you explore multiple branches at once.

You can A/B test different onboarding flows, pricing models, interfaces, and user journeys in parallel. Instead of spending weeks arguing about what should come next, you can briefly explore several paths, then quickly kill the weak ones.

That means product development starts to feel less like project management and more like portfolio management.

Not: what should we build next?
But: which possibilities deserve exploration right now?

And maybe the sprint itself needs replacing.

What if the better unit is not a sprint, but a convergence cycle — a short burst where you generate options quickly, test them, and converge on what is actually true?

Then the questions change too:

• Not: did we finish all the tickets?

• But: what did we learn?

  • What got stronger?

  • What died?

  • What should survive into the next cycle?

That is a much better operating rhythm for the AI era.

The roadmap changes too. It cannot be a fake promise anymore. It has to become more alive. Vision should stay stable. Direction matters more than ever. But the execution layer beneath it needs to stay fluid, responsive, and humble.

And the founder’s role changes with it.

The founder is no longer just managing tasks and aligning teams. The founder is increasingly orchestrating a mixed system of humans, agents, experiments, feedback, signals, and branching possibilities.

• Less process theater.

  • More judgment.

• Less ticket management.

  • More constraint setting.

• Less control.

  • More orchestration.

The principles behind Lightspeed Product Development

If I had to reduce LPD into a few principles, they would be these:

1. Build for replaceability
   Assume your stack, your workflows, and even parts of your product surface will change faster than you expect. Design modularly.

2. Validate reality, not artifacts
   Do not obsess over shipping an MVP just because the playbook says so. Focus on proving what is true about user behavior, demand, or workflow.

3. Explore in parallel
   Use agents to generate, test, and compare multiple branches at once instead of forcing everything into a single serial path.

4. Converge aggressively
   Branch widely when needed, then kill fast. Reward signal, not emotional attachment.

5. Keep vision stable, keep execution fluid
   Direction should endure. Plans should adapt.

6. Treat roadmaps as probabilistic
   A roadmap is not a promise carved in stone. It is your current best map of uncertainty.

7. Optimize for learning velocity
   The fastest startup is not the one that produces the most output. It is the one that learns the fastest per unit of time.

8. Let humans do judgment
   Let agents generate, scaffold, test, and repeat. Let humans decide, taste, interpret, and commit.

The new startup wait calculation

That is why the startup wait calculation matters.

The danger now is not just that better tools are coming.

It is that better ways of building are coming too.

A founder can start too early not just on the wrong stack, but on the wrong operating model. They can spend months inside backlog rituals, sprint logic, and roadmap theater built for a mode of software creation that is already fading.

That does not mean the answer is to wait.

Waiting is still a trap.

It means founders need to build in a way that assumes the tools will improve, the agents will improve, and the methodology itself will improve.

• Assume your stack will change.

• Assume your workflows will be replaced.

• Assume your tooling advantage will decay faster than your product insight.

• Assume that what feels like infrastructure today may look like legacy six months from now.

In space travel, the wait calculation creates an incentive trap: if future ships will be faster, why launch now? In startups, the equivalent trap is believing that because tools are changing fast, you should postpone building until the landscape stabilizes.

It will not stabilize.

The winners will not be the people who cling hardest to yesterday’s startup doctrine.

They will be the ones who can change engines mid-flight without losing direction.

In the old startup world, speed meant execution.

In the new one, speed means adaptation.

Just like in space: the old mission leaves first. The new mission arrives first.

And that is becoming true in startups too.