A tiny maintenance-pressure model

Architecture discussions often jump too quickly from “this works” to “this needs a platform.” The missing question is usually how much future change the code is expected to absorb.

This small model turns three pressures into a rough recommendation:

• how long the system is expected to live;
• how many people are likely to change it;
• how uncertain the surrounding requirements are.

It is not a decision engine. The weights are intentionally visible and simple. Its job is to make the assumptions easier to discuss.

Interactive model

Maintenance pressure

Adjust the assumptions. The model weights lifespan and contributor count slightly above uncertainty.

Expected lifespan

5 / 10

Disposable experiment → long-lived system

Regular contributors

3

One owner → a larger shared codebase

Requirement uncertainty

6 / 10

Stable problem → moving target

Pressure score4.2

4.2 out of 10

Add lightweight structure

The code is likely to repay a few explicit boundaries.

• Name ownership boundaries
• Cover important changes with tests
• Record consequential decisions

Reading the result

Low pressure suggests keeping the implementation direct and easy to replace. A middle result points towards a small amount of structure: named boundaries, focused tests, and short decision notes. High pressure makes more deliberate ownership, contracts, observability, and migration paths easier to justify.

The interesting part is not the score. It is noticing which input changed the recommendation.

A one-person tool expected to last a month can tolerate shortcuts that would be expensive in a shared service expected to survive several years. Conversely, a long-lived system with stable requirements and one careful owner may need less ceremony than its age implies.

What the model leaves out

Real decisions also depend on failure cost, regulatory obligations, data sensitivity, team familiarity, reversibility, and existing platform constraints. Those would make the model more accurate and much less useful as a quick explanation.

The component stays deliberately small: three native range inputs, derived output, no API, and no client-side framework outside the island itself.