You Learned by Building. What Needs to Change Now?

Updated September 26, 2026: This revision recognizes building as a valid way to learn. New evidence calls for a review of affected decisions, not an automatic rewrite.

You built something. People used it. The feature you thought would matter barely registered, and a small convenience became the reason somebody came back.

That is useful discovery. You have evidence you did not have when the work began.

The next question is what that evidence changes. Some of the decisions behind the product may still be right. Others may be making the next useful change harder than it needs to be.

Building can be the right way to find out

Sometimes a conversation is enough to expose a mistaken assumption. Sometimes you need to put a working thing in front of somebody and see what happens.

When an experiment becomes cheaper to build, the sensible balance can change. A narrow prototype may answer a question sooner than a detailed specification. It may also reveal that the question you were asking was the wrong one.

That does not make planning pointless. It gives planning a concrete job: decide what you need to learn and how much you are willing to commit to learning it.

Before the experiment, name the question, the behavior you will observe, and the decision the result will inform. Keep the commitment proportionate to the uncertainty. If the experiment works, make a deliberate decision about what it needs before more people depend on it.

Review the assumptions the result actually touched

Suppose a tool built for one person is now used by a team. That changes questions about ownership, permissions, and simultaneous edits. It does not automatically mean every part of the application is wrong.

Or suppose customers ignore the elaborate dashboard and keep asking for a weekly email. The next useful move may be simplifying the product rather than rebuilding its foundations.

Start with the new evidence. Trace which decisions it affects. This keeps a review connected to the product instead of becoming a list of things an engineer would prefer to build differently.

Preserve the reason, wherever the work happens

People forget. Agents can lose access to earlier context. A long chat history can contain several abandoned explanations alongside the final decision.

Record important decisions somewhere the next person or agent can find: the choice, the reason, the evidence, and what would trigger a review. Update the record when the decision changes.

If the original rationale is missing, label a reconstruction as an inference. Ask whether it is supported by the code, records, and people involved. A confident explanation written afterward is not proof of what happened.

Keep, investigate, or change

For each consequential decision, ask:

• Does it still support what customers actually need?
• What observable cost or risk does it create now?
• What would changing it improve, and what would the change cost?
• Is there a smaller intervention that would solve the problem?

Keep decisions that still fit. Investigate those where the evidence is missing. Change those with a problem worth fixing, starting with the smallest useful intervention.

“I would choose differently today” is a reason to look more closely. It is not sufficient reason to rewrite working software. You now have customers, dependencies, and learning invested in the existing system. Those belong in the decision too.

Some prototypes should be replaced. Others can become dependable products through gradual improvements. The appropriate choice depends on the system and what people need from it.

The purpose of the review is to put what you learned to work. Sometimes that means rebuilding a part. Sometimes it means leaving the code alone and changing what you plan to do next.