29 Balance foundational work with usable releases

A foundation can be necessary and still become a reason that no product reaches a user. Each layer exposes another problem worth solving. Model handling leads to runtime management. Runtime management leads to acquisition and resource ownership. Execution leads to scheduling. Scheduling leads to distributed coordination. The work can remain technically meaningful while the original application stays out of reach.

Define the smallest valuable end-to-end result

A horizontal milestone completes a layer: the registry, the scheduler, the ledger. A vertical milestone lets a person do something useful through the necessary layers.

For our running example, a vertical result could be selecting one supported resource, acquiring it, verifying readiness, and using it from a real consumer. It may support only a narrow model and runtime. That limitation is acceptable if it is explicit and the result establishes the path the product needs.

The narrow slice should not fake the difficult boundary. If a demo skips readiness checks that the real consumer depends on, it has demonstrated presentation rather than the intended outcome. The aim is a small honest path, not a broad illusion.

Write the result in terms a user can verify. “The acquisition subsystem is implemented” is weaker than “this consumer can use this selected resource after a normal acquisition and after the defined retry path.” The latter also reveals what remains outside the milestone.

Distinguish blockers from ambitions

A blocker prevents the selected result. An ambition improves or broadens a future result. They can both be important, but they should not occupy the same status.

A missing runtime capability may block the chosen model. Support for every future provider probably does not. A resource-lifecycle defect may make the slice unsafe to release. A distributed scheduler may be unnecessary for a local-only first use.

The distinction should be revisited when evidence changes. A supposedly optional feature may turn out to be required for the target user. A presumed dependency may disappear when an existing interface is understood. Keep the outcome visible so these revisions are possible.

Price temporary choices honestly

A narrow release often includes temporary decisions. They are not automatically technical debt, and they are not free. Record the condition under which they become costly.

Supporting one runtime may be a sound product boundary. Hardcoding that runtime's private layout into every consumer may make the next integration unnecessarily expensive. A local implementation can be appropriate while still preserving a clear boundary where later variation is likely.

The right question is not whether the design is future-proof. No design is. Ask whether it preserves the important current invariants and leaves a credible path for demonstrated next needs.

Match qualification to the intended use

Different projects may justify different balances. A personal tool can be useful with a narrow interface. A shared library needs clearer compatibility and failure contracts. A public service may require operational capabilities that a local prototype can defer. The development path should reflect those consequences.

A receiving institution can also set conditions that the producer’s workflow cannot decide for it. Drew DeVault’s SourceHut account reports resource-use concerns while explicitly grounding its contribution restrictions primarily in ethical and political choices. It also acknowledges useful private AI review. The account should not be converted into a technical claim that the tools never work, or a controlled estimate that generated projects always cost more. It illustrates a practical boundary: a contributor’s preferred method does not determine another project’s admission rules. SourceHut policy account.

Review the next user action

For the work in hand, write the next useful action a person should be able to perform. Identify the one or two missing capabilities that actually prevent it. Then ask whether current foundational work removes those blockers.

If it does, the connection should be easy to explain. If it does not, decide deliberately whether the research value justifies the delay. This is not a demand to abandon long-term work. It is a way to preserve agency over how much of the present is being spent on the future.

The practical risk is not ambition itself. It is losing the line from today's work to a result someone can eventually use and evaluate.