Post-PMF Hardening Roadmap

Reinforce the Road Carrying Traffic

Post-PMF hardening begins when a particular failure has become more expensive than the work needed to prevent, expose, or recover from it. It does not begin when the whole product feels mature enough for an infrastructure programme.

Choose one customer segment and one path that now carries retained use, money, important data, trust, or repeated founder intervention. Write the path as a sequence a customer would recognize:

VALUE PATH
Segment:
Path from first action to retained outcome:
Evidence that customers depend on it:
Customer promise now being made:
Founder rescue or explanation it repeatedly requires:
Hardening cycle ends on:
Founder capacity available during this cycle:

If the evidence is still a handful of hopeful conversations, return to search work. If paying customers depend on only one narrow workflow, harden that workflow rather than the architecture around every possible future product. Security, privacy, money, and destructive data risks are the exception to a simple popularity test: a plausible severe harm deserves treatment even at low volume.

Find the Weakest Promise

Walk through the value path from the customer’s action to the durable outcome. At each transition, ask what can fail, what the customer would lose, how the founder would discover the failure, and whether recovery is safe. Include the boundaries that are easy to leave outside an application diagram: invitations and offboarding, billing and entitlement changes, background jobs, third-party delivery, exports, deletion, support actions, and releases.

Do not turn the walk into a catalogue of everything imperfect in the codebase. Record a weakness only when you can connect it to a customer promise, a serious trust boundary, a growing cost, or recurring founder work.

WEAKNESS
Point in the value path:
Observed failure, near miss, support pattern, or measured constraint:
Customer consequence:
How failure is detected today:
Recovery available today, including unsafe ambiguity:
Founder time or interruption created:
Evidence link—incident, support case, metric, account, or trace:

Prefer observations to adjectives. “Three failed notification jobs were found by customers and required raw-log repair” can guide work. “Notifications are fragile” cannot.

Give Every Weakness One Disposition

Place each recorded weakness in one of four lanes.

Protect now is for a proven promise or trust boundary whose failure can harm customers, revenue, important data, or the founder’s ability to operate. Protection may be a state transition, a regression test, an alert, a safe retry, a restore rehearsal, a limit, or removal of a dangerous path. It is not automatically a new platform.

Instrument is for a plausible bottleneck whose cost or shape is still unclear. Measure at the customer boundary: queue age before a promised deadline, latency by account size, restore time, failed renewals, support time, or cost per active account. Name the threshold that would cause action.

Simplify is for surface area that creates permissions, support, testing, cost, or operational branches without carrying enough value. Deletion, narrowing a promise, or replacing customization with a maintained default can be hardening work.

Defer is for a risk the current product can safely carry. Write why it is safe enough now and the event that reopens it. “Later” is not a disposition.

The lanes are choices, not stages. A deferred item does not graduate merely because time passes, and an instrument item should not quietly become a rewrite before its threshold is crossed.

Turn the First Choice into Work

Choose one or two protect-now items that fit the cycle’s real capacity. Write each as a reduction in risk, not a component to install.

HARDENING ITEM
Promise protected:
Evidence that makes the work timely:
Failure or harm being reduced:
Smallest control that changes that risk:
How the control will be verified:
Recovery path after the change:
Customer or operator documentation required:
Owner:
Target date:
Stop condition:
Work explicitly excluded:

“Add observability” has no boundary. “Record final delivery state, alert after retries are exhausted, and expose a safe replay action” names a failure, a control, and an operator response. The stop condition keeps that useful fix from expanding into a general observability project.

Sequence the item from uncertainty toward safety. Make the important state visible before automating a response to it. Preserve evidence before adding a destructive repair. Establish a recovery path before promising uninterrupted service. Remove an unjustified branch before writing tests to preserve it. Prevention is valuable, but a founder also needs to know when prevention failed and what can be done without multiplying harm.

A Bounded Example

A scheduling product has retained property-management customers. Vendor assignment is part of their daily work, but notification delivery sometimes fails after a provider timeout. Customers discover the miss, and the founder cannot tell whether replay will create a duplicate appointment.

The roadmap protects notification delivery now: give each delivery a durable identity and visible state, make replay safe, alert only after automatic recovery is exhausted, and test duplicate and partial-failure behavior. It instruments queue age by account before changing queue architecture. It simplifies custom notification rules used by one dormant account. It defers a second region until dependency or recovery expectations exceed what the current design can meet.

The cycle stops when failed deliveries are visible before a customer reports them, recovery does not duplicate the business action, and the founder can resolve the failure without raw-log diagnosis. That is a meaningful increase in durability. A new messaging platform is not required to declare the cycle complete.

Close and Re-rank

At the end of the cycle, verify the customer outcome rather than the presence of new machinery. Rehearse the recovery path where doing so is safe. Check that the alert reaches an action, the test covers the consequential failure, the runbook matches the product, and temporary bypasses have been removed or given an owner.

Then record what the cycle taught:

CYCLE REVIEW
Promises made more durable:
Evidence that the controls work:
Founder intervention removed or shortened:
New cost, complexity, or failure mode introduced:
Weakness promoted, simplified, or deferred next:
Evidence that would reopen this cycle:

The roadmap is ready when it identifies the path carrying real traffic, makes the most consequential weakness actionable, protects time for a bounded response, and says what will remain soft. Its purpose is not to make every road permanent. It is to keep the road customers already rely on from depending on luck or founder heroics.