You inherit a well-designed plan for a new order-management platform: eight months, event-sourced, three services, a migration path off the legacy system. The business now needs working functionality in ten weeks for a contractual commitment. How do you sequence this so the ten-week work is not thrown away?

The sequence

The instinct is to build a fast tactical version now and the real one later, which produces two systems and a team maintaining both. The better sequence is to build the first slice of the real architecture and skip its generality, so what ships in ten weeks is a subset rather than a substitute.

1. Weeks 1-2: fix the boundary, not the internals. Define the API and the events the new platform will emit, because these are what other teams and future services couple to. Interfaces are the expensive thing to change later; implementations are not. If the events are right, you can rewrite everything behind them.
2. Weeks 2-6: one service, one database, synchronous. Implement the slice the contract actually requires — say order capture and status — inside a single deployable using a plain relational schema. No event store, no three services, no CQRS. The domain logic lives in modules with the boundaries the eventual services will have, which costs nothing now and is the whole reason this is not throwaway.
3. Weeks 6-9: run in parallel with the legacy system for a subset of traffic. 5% of orders, with reconciliation that compares outcomes and alerts on divergence. This is the step teams cut under deadline pressure, and it is the one that makes the deadline safe, because it converts go-live from an event into a dial.
4. Weeks 9-10: cut over the contracted scope, keep the legacy path live behind a flag for the rest.

What is deliberately discarded

The event store, the service split, and the migration of everything else. Each is a real part of the eight-month plan and none of them is needed to serve one slice of traffic. The judgement is that they are additive later: you can introduce an event log behind a module boundary, and you can extract a service from a module whose interface already exists. You cannot cheaply undo a data model that other teams have coupled to.

Where it can still go wrong

• The modules become one tangle because there was no time to keep them honest. The cheap defence is an automated dependency check in the build that fails when the wrong module imports another.
• The parallel run is skipped, and cutover becomes a gamble. Protect it explicitly: it is the step that buys the rollback.
• The ten-week version is declared done. This is the real risk, and it is organisational, not technical. Write down what was deferred, why, and what triggers it, and get the business to acknowledge the list in the same conversation where they got the date.

How long it really takes

Ten weeks for the slice is achievable with three or four engineers if the scope is genuinely one flow. The eight-month plan does not become nine; it becomes twelve to fourteen for the full scope, because the parallel run, the flag and the two-path period are real work. The trade is honest: you deliver 10% of the value in 15% of the time, and you pay perhaps 25% more in total for the privilege of having shipped early and of having learned from production.

When this is the wrong answer

If the ten-week scope cannot be expressed in the target architecture at all — it needs a data model the new design rejects, or it is a fundamentally different product — then two systems is the honest answer, and the tactical one should be explicitly time-boxed with a deletion date and no new features. And if the eight-month design is itself unjustified, a deadline is a good moment to notice: a plan that cannot produce anything useful in ten weeks is sometimes not a plan with a sequencing problem, it is a plan with a scope problem.