8. Project: design Mercado's evolution for a change

Overview

This is your graduation from the module. Over seven lessons you installed the stance of the architect who designs for change: you saw that no architecture is final —it's a flow of decisions (lesson 2)—, you learned to value optionality and its break-even point (lesson 3), to use sacrificial architecture to buy cheap information (lesson 4), to recognize the two abysses —over-engineering (lesson 5) and under-engineering (lesson 6)— and to find the sensible point between them with right-sizing (lesson 7). All of that you saw applied to situations we gave you already solved. Now it's your turn, from scratch, on a new case we didn't analyze in any lesson. The reason for changing the case is the usual one and it's hard: if I let you redo a portfolio from the lessons, I wouldn't know whether you learned the method or memorized the answer. With a new case, the only way to solve it is to apply the method —and that is, exactly, the proof that the module worked—.

Your deliverable is the planned evolution of Mercado facing a new launch, in three artifacts: (1) the portfolio of anticipated changes the launch triggers, each with its probability and impact; (2) the executed measurement of the three stances —rigid, over-engineered, and right-sized— in Python, which says how much each one costs and which seams to build; and (3) the evolution plan that distributes the changes into three buckets —build the seam today, prototype (sacrificial) the uncertain, and defer (YAGNI) the improbable— plus the script of how you explain it to the stakeholder who approves the budget. No part requires building the system: it's pure evolution-design work —anticipate, measure, plan—, which is exactly what separates an architect who designs for change from one who only reacts to it. Build it yourself first; reading the reference solution without having tried it is like reading the scoreboard of a game you didn't play.

Connection with the module: this project closes the arc. Lessons 2 to 4 gave you the stance (flow, optionality, sacrificial); lessons 5 to 7 gave you the criterion (the two abysses and the right-sizing that avoids them). Here you produce the three artifacts with your own hands, from start to finish, on a new case. And with this lesson the module closes: at the end is the summary of the eight lessons and the bridge to module 7, where you'll learn to document the evolution you now know how to plan —so the plan survives time and the turnover of people—.

The project case: Mercado launches Mercado Plus

The new situation —yours to solve— is this:

Mercado wants to launch Mercado Plus, a paid membership (like the subscriptions of the big marketplaces): the customer pays a monthly fee and in exchange gets free shipping, early access to deals, and an exclusive catalog. Leadership is excited and in a hurry. The VP of product hands you a roadmap of anticipated changes the launch is going to trigger in the system, and asks you, as architect: "of all this, what do we build now to be ready, what do we leave for later, and where are you less sure? I need to know what budget to request this quarter". Your job is to answer with the module's method —not with intuition—.

The roadmap of changes the VP gives you, each with what you know about it (we give you the numbers so you don't have to make them up, just as a real team would give you estimates):

• membership_billing_recurring — recurring charging of the monthly fee (cycles, proration, retries of failed charges). Practically certain: no recurring billing, no membership. p = 0.95. Cheap seam (seam = 6000), later adaptation 5000... —or a rewrite of 60000 if no seam is left—.
• free_shipping_rules_engine — free-shipping rules for members (thresholds, zones, exceptions). Almost certain: it's the flagship benefit. p = 0.90, seam = 5000, adapt = 6000, rewrite = 45000.
• early_access_scheduling — scheduling members to see deals before everyone else. Probable. p = 0.60, seam = 4000, adapt = 5000, rewrite = 20000.
• exclusive_catalog_segment — a catalog segment visible only to members. Uncertain: depends on whether deals with sellers are secured. p = 0.40, seam = 7000, adapt = 6000, rewrite = 22000.
• tiered_pricing_experiments — experimenting with several membership tiers (Plus, Premium). Very uncertain: no one knows if customers will want tiers or which ones. p = 0.20, seam = 9000, adapt = 7000, rewrite = 24000.
• partner_perks_marketplace — a marketplace of third-party perks (partner discounts). Imagined, no one asked for it. p = 0.05, seam = 22000, adapt = 14000, rewrite = 40000.
• points_and_rewards_ledger — a points and rewards system like a loyalty program. Imagined, no concrete demand. p = 0.08, seam = 18000, adapt = 12000, rewrite = 30000.

Notice the mix, because it's deliberate and it's where the method is tested: there are almost-certain changes (billing, free shipping), probable ones (early access), uncertain ones (exclusive catalog, pricing tiers), and improbable imagined ones (partner marketplace, points). Leadership, in a hurry, might want to "build it all to be ready" (over-engineering) or "launch the minimum and we'll see" (under-engineering). Your method should have something better to say. Don't redesign how a recurring-billing system or a shipping-rules engine works —that's for other guides—; your job is to plan the evolution: decide where to leave a seam, where to prototype, and where to defer.

What you have to deliver

Follow the steps in order; each rests on the previous one.

Part 1 — The portfolio of anticipated changes

Organize (in text or a table) the VP's roadmap as a portfolio, ordered by probability, making clear for each change its p, its seam cost and its rewrite cost. Before measuring, mark by eye what you expect: which changes "smell" like a clear seam, which like a defer, and which give you doubt. This is reading the business's signals (lesson 7) before the code confirms them.

Part 2 — The executed measurement

Write and run the Python that measures, for the portfolio, the three stances: rigid (no seams), over_engineered (all the seams) and right_sized (seam where it pays for itself, defer the rest), deciding future by future with the break-even point. Deliver the real, run numbers, not cited from memory, and the list of which seams right-sizing builds and which it defers. Reuse the formulas from lesson 7.

Part 3 — The evolution plan (and the script for the stakeholder)

Distribute the changes into three buckets and justify each one with the method:

• Build the seam today — the probable changes where right-sizing says build. Remember: the seam, not the solution (reserve the right of way, don't pave the avenue).
• Prototype (sacrificial) — the uncertain changes where the doubt isn't "will it come?" but "what is it that's really needed?", and a cheap disposable prototype reduces that uncertainty before committing (lesson 4). Not everything right-sizing defers is deferred blindly: something may deserve an experiment that learns its true probability.
• Defer (YAGNI) — the improbable imagined futures where you leave neither a seam nor a prototype (lesson 5).

And close with the script —three or four sentences— of how you explain to the VP what budget to request and why, in their language (money and risk), not yours (seams and probabilities).

The rubric

This is how the project is evaluated. It's not by length or elegance: it's by whether the evolution plan is well made and well defended with evidence.

Criterion	Doesn't meet	Meets	Excels
Portfolio	Lists the changes with no probability or impact	Each change with p, seam and rewrite	Also marks by eye, before measuring, what it expects of each one by reading the business's signals
Executed measurement	Numbers cited from memory or made up	The three stances run in Python, with the list of seams	Also states which business signal supports each probability
Evolution plan	A single bucket ("let's do everything" or "the minimum")	The three buckets (seam / prototype / defer) justified with the method	Also distinguishes seam from solution, and uses the sacrificial prototype where the uncertainty is of requirements, not of probability
Script for the stakeholder	Absent, or speaks in technical jargon	Explains the budget in money and risk	Also names what's deferred and why, and leaves the plan as something to be revised

The criterion that weighs most, and the one that separates an architect who designs for change from one who reacts to it, is the executed measurement crossed with the three-bucket plan: if you deliver everything else but the numbers came out of your head, or if you put everything in a single bucket (all seam, or all deferred), you didn't design the evolution —you guessed—.

The reference solution

Attempt the whole project before continuing. What follows is one correct solution, not the only one.

Part 1 — The portfolio, with what's expected by eye

The roadmap ordered by probability, with the prior reading of the business's signals:

change                            p      business signal                     by eye
──────────────────────────────    ────   ───────────────────────────────    ──────────────────────────────
membership_billing_recurring      0.95   no billing, no membership           clear seam
free_shipping_rules_engine        0.90   it's the flagship benefit           clear seam
early_access_scheduling           0.60   promised in the Plus pitch          seam (probable)
exclusive_catalog_segment         0.40   depends on deals with sellers       DOUBT
tiered_pricing_experiments        0.20   no one knows if there'll be tiers   DOUBT (requirements uncertainty)
partner_perks_marketplace         0.05   no one asked, no strategy           defer (YAGNI)
points_and_rewards_ledger         0.08   imagined, no demand                 defer (YAGNI)

What's expected by eye, before measuring: the first two (billing, free shipping) are very clear seams —very high probability, without them there's no product—. early_access_scheduling is probable and also smells like a seam. The last two (partner_perks, points) are imagined futures with no demand: defer, clearly (over-engineering if I build them). And two doubts remain: exclusive_catalog_segment (0.40) is in the gray zone of probability; tiered_pricing_experiments (0.20) is a special doubt —its uncertainty isn't so much "will it come?" but "what will the customers want?", which smells like a sacrificial prototype more than a seam or a blind defer—. The measurement will confirm the two clear seams and the two defers; the two doubts must be resolved with the number.

Part 2 — The executed measurement

# Project: design the EVOLUTION of Mercado for the launch of "Mercado Plus"
# (a paid membership). Leadership hands over a roadmap of anticipated changes and
# asks: what do we build today, what do we defer, and where is a prototype worth it. Right-sizing:
#   p       : probability that the change arrives
#   seam    : cost of building the seam today
#   adapt   : cost of adapting LATER if there's a seam
#   rewrite : cost of rewriting if there's NO seam
PORTFOLIO = [
    # (name, p, seam, adapt, rewrite)
    ("membership_billing_recurring", 0.95,  6000,  7000, 60000),
    ("free_shipping_rules_engine",   0.90,  5000,  6000, 45000),
    ("early_access_scheduling",      0.60,  4000,  5000, 20000),
    ("exclusive_catalog_segment",    0.40,  7000,  6000, 22000),
    ("tiered_pricing_experiments",   0.20,  9000,  7000, 24000),
    ("partner_perks_marketplace",    0.05, 22000, 14000, 40000),
    ("points_and_rewards_ledger",    0.08, 18000, 12000, 30000),
]


def cost_build(p, seam, adapt, rewrite):
    return seam + p * adapt


def cost_defer(p, seam, adapt, rewrite):
    return p * rewrite


rigid_total = over_total = right_total = 0
built, deferred = [], []
print(f"{'roadmap change':<32}{'p':>6}{'build':>10}{'defer':>10}   decision")
print("-" * 76)
for name, p, seam, adapt, rewrite in PORTFOLIO:
    b = cost_build(p, seam, adapt, rewrite)
    d = cost_defer(p, seam, adapt, rewrite)
    rigid_total += d
    over_total += b
    if b <= d:
        right_total += b
        decision = "BUILD seam"
        built.append(name)
    else:
        right_total += d
        decision = "defer (YAGNI)"
        deferred.append(name)
    print(f"{name:<32}{p:>6.2f}{b:>10,.0f}{d:>10,.0f}   {decision}")
print("-" * 76)
print(f"{'rigid (0 seams)':<48}{rigid_total:>10,.0f}")
print(f"{'over_engineered (seam for EVERYTHING)':<48}{over_total:>10,.0f}")
print(f"{'right_sized (planned evolution)':<48}{right_total:>10,.0f}")
print()
print(f"Build TODAY: {', '.join(built)}.")
print(f"Defer (YAGNI): {', '.join(deferred)}.")
print(f"right-sized vs rigid savings: {rigid_total - right_total:,.0f} USD.")
print(f"right-sized vs over-engineered savings: {over_total - right_total:,.0f} USD.")

What to expect. On running it:

roadmap change                       p     build     defer   decision
----------------------------------------------------------------------------
membership_billing_recurring      0.95    12,650    57,000   BUILD seam
free_shipping_rules_engine        0.90    10,400    40,500   BUILD seam
early_access_scheduling           0.60     7,000    12,000   BUILD seam
exclusive_catalog_segment         0.40     9,400     8,800   defer (YAGNI)
tiered_pricing_experiments        0.20    10,400     4,800   defer (YAGNI)
partner_perks_marketplace         0.05    22,700     2,000   defer (YAGNI)
points_and_rewards_ledger         0.08    18,960     2,400   defer (YAGNI)
----------------------------------------------------------------------------
rigid (0 seams)                                    127,500
over_engineered (seam for EVERYTHING)               91,510
right_sized (planned evolution)                     48,050

Build TODAY: membership_billing_recurring, free_shipping_rules_engine, early_access_scheduling.
Defer (YAGNI): exclusive_catalog_segment, tiered_pricing_experiments, partner_perks_marketplace, points_and_rewards_ledger.
right-sized vs rigid savings: 79,450 USD.
right-sized vs over-engineered savings: 43,460 USD.

Read the three totals and then the cutoff line, because there's the answer to the VP.

The three totals: rigid 127500, over-engineered 91510, right-sized 48050. The right-sized plan dominates the two extremes, just as in lesson 7: it saves 79450 against launching with no seams (rigid) and 43460 against building for everything (over-engineered). Neither leadership's hurry to "do it all" nor the shortcut of "launch the minimum" comes close to planning the evolution with criterion.

The cutoff line falls between early_access_scheduling (0.60) and exclusive_catalog_segment (0.40). Right-sizing builds seams in the top three —where build is cheaper than defer— and defers the bottom four. Look at the two border cases: in early_access (0.60), building costs 7000 against 12000 to rewrite → build. In exclusive_catalog (0.40), building costs 9400 against 8800 to rewrite → defer, by a little. The 0.40 probability, with that seam and that rewrite, no longer suffices to justify the seam. And the two imagined ones (partner_perks at 0.05, points at 0.08) are deferred by an enormous margin: building their seams would cost 22700 and 18960 against an expected rework of barely 2000 and 2400. They'd be pure over-engineering.

Notice something the measurement alone doesn't capture and that Part 3 has to resolve: right-sizing defers tiered_pricing_experiments (0.20) —building costs 10400 against 4800 to rewrite—, and that's correct for a seam. But its uncertainty is of another kind: it's not "will the pricing tiers come?" but "what tiers will the customers want, if they want any?". That's requirements uncertainty, the one lesson 4 resolves with a sacrificial prototype. Deferring the seam doesn't mean deferring the learning. Part 3 takes this case out of the "defer blindly" bucket and puts it in the "prototype" bucket.

Part 3 — The evolution plan, in three buckets

With the measurement done, the plan distributes the seven changes like this:

Bucket 1 — Build the seam today (the three right-sizing marked, high probability):

• membership_billing_recurring — leave the seam for recurring charging: a "billing cycle" interface separated from the one-time-purchase checkout, with its own subscription tables. Don't yet build every proration and exotic-retry case; leave the boundary that will make adding them cheap. (Seam, not solution.)
• free_shipping_rules_engine — leave the seam for the shipping rules: a clear point where the "does this order have free shipping?" logic is evaluated, separated from the general shipping calculation. Start with today's simple rule (member → free); the seam makes adding thresholds and zones cheap later.
• early_access_scheduling — leave the seam for early access: a notion of "visibility by customer segment" in the catalog, instead of hardcoding "everyone sees everything". Cheap today, and it prepares both early access and the future exclusive catalog.

Remember the nuance of lesson 7: in all three, you build the seam (interface, boundary, contract —thousands of dollars), not the complete solution (the billing system with all its cases, the configurable rules engine —tens or hundreds of thousands). You reserve the right of way; you don't pave the avenue.

Bucket 2 — Prototype (sacrificial) (the requirements uncertainty):

• tiered_pricing_experiments — right-sizing deferred it as a seam, and rightly: with p = 0.20, building the pricing-tier machinery would be premature. But deferring the seam doesn't mean staying blind. The real doubt here is of requirements —do customers want tiers? which ones? at what price?—, and that's resolved with a sacrificial prototype (lesson 4): a cheap, disposable experiment —a landing page with two or three fictitious tiers, or a small A/B with a subset of customers— whose only job is to learn whether tiers move the needle. It's thrown away after measuring. It costs little, and if it turns out customers do want tiers, tiered_pricing rises from 0.20 to a high probability and then it enters bucket 1 at the next review. You neither build the seam nor defer it blindly: you buy the information that will say which of the two to do.

Bucket 3 — Defer (YAGNI) (the improbable imagined ones):

• exclusive_catalog_segment (0.40), partner_perks_marketplace (0.05) and points_and_rewards_ledger (0.08) — defer them. The last two are imagined futures with no demand (no one asked for them, no strategy): building their seams would be expensive over-engineering (22700 and 18960 to avoid 2000 and 2400 expected). exclusive_catalog_segment is a finer case: its probability (0.40) leaves it on the defer side by a little, and besides, the early_access seam (which you do build) already leaves half a door open —the "visibility by segment"— in case it rises. Defer them, but revise them: if the deals with sellers close, exclusive_catalog rises and changes bucket.

The script for the VP (in their language —money and risk—, not yours):

"For Mercado Plus, I'm requesting budget this quarter for three things: the recurring billing, the free-shipping rules, and the early access —they're almost certain, without them there's no product, and preparing them now costs us a fraction of what improvising them later would cost—. I'm not going to request budget for the partner marketplace or the points system: no one has asked for them, and building them now would be spending on something we probably won't use. And for the pricing-tiers idea, instead of building it or discarding it, I propose a cheap experiment that tells us in a month whether customers really want them —so we decide with data, not with hunches—. In total, this plan saves us about 79 thousand dollars versus launching with no preparation and about 43 thousand versus building it all. And it's not a final decision: we revise the plan every quarter, because if the business changes —if we close exclusive-catalog deals, for example—, what we defer today can move to being built."

Notice how the script translates the whole module into the stakeholder's language (lesson 5): it doesn't talk about seams, probabilities or break-even points; it talks about what's requested, what isn't, why, how much is saved and that the plan will be revised. The architect who designs for change doesn't just plan the evolution; they know how to explain it to whoever signs the check.

Exercises

These exercises transfer the method to other Mercado decisions, so you confirm you learned to design the evolution and not to repeat a portfolio.

Exercise 1 — The change that changed probability. Three months after the Plus launch, the data from the sacrificial prototype of tiered_pricing_experiments arrives: customers do want a Premium tier, strongly. The probability that the pricing tiers arrive rises from 0.20 to 0.85. Without running code, recalculate its build and defer options with the new probability (use seam=9000, adapt=7000, rewrite=24000), say which bucket it moves to now, and explain what role the prototype played in this transition.

See solution

With tiered_pricing_experiments at p = 0.85:

• build = seam + p × adapt = 9000 + 0.85 × 7000 = 9000 + 5950 = 14950.
• defer = p × rewrite = 0.85 × 24000 = 20400.

Now build (14950) is cheaper than defer (20400), so it moves from bucket 3/2 (deferred / prototyped) to bucket 1 (build the seam today). The pricing-tier seam now pays for itself, when at p = 0.20 it didn't.

The role of the prototype: it was exactly what made this transition possible with criterion instead of blindly. When the probability was 0.20, there were two bad ways to act and one good one. Bad number one: build the seam anyway (over-engineering, 10400 to avoid 4800 expected). Bad number two: defer and forget (potential under-engineering: if the tiers turned out a success, they'd arrive to find no seam). The good one: the sacrificial prototype —buying the cheap information that resolved the requirements uncertainty—. The prototype didn't just answer "which tiers do they want?"; in doing so, it updated the probability from 0.20 to 0.85, moving the change between buckets. This illustrates the module's circularity (lesson 7): right-sizing is a flow that's revised, the prototype (lesson 4) is a tool to reduce the uncertainty that feeds that revision, and no decision —not even to defer— is final. The prototype turned a doubt into a datum, and the datum turned a defer into a seam.

Exercise 2 — Leadership's hurry. The VP, excited, proposes: "while we're at it, let's also build the partner marketplace and the points system now, to launch Plus with everything and not come up short". With the numbers from the measurement, give them two reasons not to do it, and name which module mistake they'd be making.

See solution

The VP would be making over-engineering (lesson 5): building flexibility for imagined futures almost no one has asked for. Two reasons with the numbers:

Reason 1 — the disproportionate cost against the probability. Building the partner_perks_marketplace seam costs 22700, and the points_and_rewards_ledger one costs 18960 —together, over 41000—. But their probabilities are tiny (0.05 and 0.08): the expected rework of not building them and adapting if they happen to arrive is barely 2000 and 2400 —together, 4400—. That is, the VP wants to spend 41000 to avoid an expected cost of 4400: paying almost ten times too much for flexibility that almost surely won't be used. It's insuring the house against dragons.

Reason 2 — the carrying cost and the distraction. Beyond building them (the 41000), those two capabilities —a third-party marketplace, a points ledger— are complex systems that would have to be carried over the whole life of Mercado Plus: every future change would have to respect them, every new dev would have to learn them, and all that for features no one asked for. And there's an opportunity cost: the team would be building that instead of polishing the recurring billing and the free shipping, which are what really makes or breaks the launch. Building "with everything so as not to come up short" isn't being prepared; it's diluting the effort into the improbable at the expense of the sure.

The answer to the VP: "coming up short would be not preparing the probable —and we are preparing that (billing, shipping, early access)—. The partner marketplace and the points aren't 'coming up short'; they're building for a future no one has asked for. If someday there's real demand, we build them then, and waiting will have cost us almost nothing. Building them today costs us 41 thousand and distracts us from what makes the launch work." It's distinguishing "designing for change" (probable) from "designing for every change" (imaginable), the central phrase of lesson 7.

Exercise 3 — Another evolution, same method. Mercado wants, separately, to evolve its search system: there are rumors it might need voice search, image search, and support for a new language. Without running code, describe how you'd apply the module's complete method (portfolio, measurement, three buckets) to this case, and what questions you'd ask to assign the probabilities. Give the criterion, not a fixed answer.

See solution

The method is the same, applied to this new portfolio. The steps:

Portfolio. I'd list the anticipated changes —voice_search, image_search, new_language_support, and perhaps others the signals suggest— and for each I'd estimate p (probability), seam (cost of leaving the seam), adapt (adapting with a seam) and rewrite (rewriting without it). I'd order by probability.

Measurement. I'd run the same right-sizing of the three stances: rigid (0 seams), over_engineered (all) and right_sized (seam where build ≤ defer, defer the rest), future by future. The totals would say how much planning saves against the two extremes, and the cutoff line would say which seams to build.

Three buckets. I'd distribute: build the seam in the probable changes (for example, if the business is already committed to a new language, leave the internationalization seam for search); prototype where the uncertainty is of requirements (would customers really use voice search? a disposable prototype would tell before building the seam); defer the improbable imagined ones (if image search is a rumor with no demand, build nothing).

The questions to assign probabilities —and here's the criterion, because probabilities are derived from signals, not made up (lesson 7)—:

1. What is the business signaling? Is there a product commitment, an announcement, a customer demand, a competitor who already did it? A new language with an announced expansion is probable; a voice search someone "thought up" is imagined.
2. What pain do the squads or the users already report? (Lessons 2 and 5.) If support gets many complaints about search in another language, the probability rises.
3. Is the uncertainty about "whether it will come" or about "what we need"? If the first, you decide seam vs defer; if the second, you prototype (lesson 4).
4. What's the cost asymmetry? (Lesson 6.) For the doubts near the break-even point, would coming up short hurt much more than overshooting? If so, lean toward the seam.

The criterion, in one phrase: the method doesn't give fixed answers —it gives a procedure (portfolio → measurement → three buckets) fed by the real signals of the business—. What you learned isn't "what to do with voice search", but to ask the right probabilities, measure the right-sizing, and distribute into seam / prototype / defer. That's designing the evolution of any system, not repeating Mercado Plus's.

Module summary and where you go next

With this project you close module 6, the architect's stance toward time. You started with the thesis —no architecture is final: it's a flow of decisions, measured in the half-life of Mercado's design, where only 25% of the day-one assumptions survives to year 5 (lesson 1)—. You turned it into an operational stance: the architecture isn't a snapshot that freezes but a film, and what breaks it isn't a change but the accumulation —treating it as final costs 2.7x over the system's life— (lesson 2). You learned to value the open doors: optionality has value like insurance, but it costs a premium, and its break-even point (8.3% in the example) says when it's worth it and when it's wasted (lesson 3). You discovered the most counterintuitive tool: sacrificial architecture, building to throw away and buying cheap information —a 15000 prototype eliminates an uncertainty that would cost 60000 expected in rebuild— (lesson 4). You marked the two abysses: over-engineering, preparing for everything imaginable, which pays 25x for unused flexibility (lesson 5); and under-engineering, painting yourself into a corner, which costs 4.3x when the probable change arrives with no seam (lesson 6). And you found the path between them: designing the seams with right-sizing, which dominates the two extremes (43050 against 90610 and 133550) because it decides future by future with the probability, not with fear or laziness (lesson 7). Here, in the project, you did it all yourself on a new case: you assembled the portfolio, measured the three stances, distributed into seam/prototype/defer, and explained it to the stakeholder.

The capability you take away: facing any system and any list of changes the business might ask for, you can read the signals to estimate probabilities, measure the cost of the three stances, and decide with numbers which changes to leave a seam for today, which to prototype, and which to defer —without falling into the over-engineering that builds for everything or the under-engineering that builds for nothing—. You stopped treating the architecture as an artifact that gets finished and started treating it as a flow that positions itself for change.

Where you go next, within this guide:

• Module 7 — Documentation that survives. You now know how to plan the evolution; module 7 teaches you to document it so it survives time and the turnover of people: living documentation, the C4 + ADR + arc42 combo, docs-as-code, the README that does onboarding, and the bus factor. The evolution plan you assembled here —which seams you left, what you deferred and why— is worth nothing if it lives only in your head: the architect who leaves takes the why with them, and the arriving squad blindly reverts the seams it cost so much to leave. Documenting the evolution is what makes this module's stance survive the person who had it.

And toward the rest of the ecosystem: every time this module spoke of "leaving a seam", "one-way or two-way doors", "technical debt" or "the last responsible moment" without re-teaching its mechanics, it rested on the sister guide architecture-decisions-and-tradeoffs, which does teach it. You now have what no technical guide covers: the mental stance of the architect who plans for change —the disposition to see the system as a film, keep options under uncertainty, build to throw away, and walk between the two abysses—. The tools are learned in the other guides; the craft of wanting to use them to design the evolution, and knowing when and how much, is from this one.

Resources

• Neal Ford, Rebecca Parsons and Patrick Kua — Building Evolutionary Architectures — the natural close of the module: the whole book is the manual of how to design and guide systems that evolve, exactly what you did in this project. In English.
• Martin Fowler — "Sacrificial Architecture" and "Yagni" — the two essays that name the two most counterintuitive pieces of the module (building to throw away, and not building for the improbable), applied in this project's prototype bucket and defer bucket. In English.
• Andrew Hunt and David Thomas — The Pragmatic Programmer, 20th Anniversary Edition — the topics "Reversibility", "Good-Enough Software" and "Prototypes and Post-it Notes" condense the module's stance: there are no final decisions, software evolves, and prototyping to learn is wisdom, not waste. In English. The mechanics of decisions under change (reversibility, last responsible moment, technical debt) is the sister guide architecture-decisions-and-tradeoffs.