The first product is not just a product: it is the factory for the second

A team finishes the first product exhausted. The software works, but everything that made it possible to build it is trapped in conversations, local commands and unrecorded decisions. The next product starts almost from scratch.

Another team ends up with less apparent shine, but leaves reusable templates, contracts, pipelines, criteria, learnings and limits. The second product comes with an advantage that does not appear on the screen of the first.

Executive summary

The first product delivers value to a recipient and, at the same time, teaches the organization how to deliver again.

Reusing does not mean copying everything. It means preserving what reduces uncertainty without carrying undue coupling.

The factory is not a giant platform

Building a “platform for all future products” before having the first user tends to crystallize hypotheses too early.

The factory starts small:

• reproducible repository structure;
• minimum conventions and policies;
• pipeline that makes failure visible;
• configuration contracts and secrets;
• way of recording decisions;
• deployment and rollback path;
• learning catalog;
• templates extracted from observed repeats.

Each asset needs to justify the cost of maintaining it.

Product, platform and method learn together

The product reveals what the customer needs. The platform reveals what the team repeats. The method reveals how decisions are made and corrected.

If the team extracts an abstraction before observing repetition, it creates an obligation. If you never extract, you repeat mistakes and manual work. The right moment appears when:

1. the pattern happened more than once;
2. relevant differences are understood;
3. there is maintenance owner;
4. the benefit outweighs the coupling;
5. there is an escape path for special cases.

DORA relates platform quality to how AI adoption translates into software development performance. This evidence does not prove a universal architecture; reinforces that the tool operates within an organizational system. [CAREER-A18-C5]

What should survive the first product

Intention

Why the product exists, for whom and what decision improves. Without this, the next team inherits code for no reason.

Contracts

Interfaces, events, data, capabilities and limits. Useful contract allows evolution; does not freeze the entire implementation.

Verification

Tests and evals that protect important behavior, including negative cases and regressions from real incidents.

Evidence

Claims linked to assets, environments, dates and checkers. A “green” without subject is not reliable inheritance.

Apprenticeship

Observed problem, decision, mechanism, result and limit. Lesson without system change becomes just narrative memory.

Inheritance needs to be opt-in and versioned

The second product should not automatically receive everything from the first. It selects a versioned baseline:

seed -> aplicar módulos -> declarar desvios -> validar -> assumir ownership

This avoids two opposite faults:

• eternal fork: each product silently copies and diverges;
• compulsory platform: a central change breaks different contexts.

A template needs to declare what is a foundation, what is an example and what depends on the product.

The factory cost is included in the account

Shared assets are not free. Measure:

• time saved on bootstrap;
• defects avoided or detected earlier;
• update lead time;
• abstraction support cost;
• frequency of exceptions;
• number of products they actually adopt;
• time to abandon a bad choice.

An abstraction used by a single product might just be ambitiously named product code.

The second product tests the factory

The first product may work by tacit knowledge. The second reveals whether the inheritance is real.

Do a clean test:

1. start from the approved seed;
2. do not manually copy files from the first;
3. record gaps and undocumented steps;
4. measure time to first verifiable slice;
5. handle all generic corrections in the foundation owner;
6. keep product specific decision.

Multi-agent architectures and decision logs show that roles and durable history help coordinate work, but do not prescribe a single topology or template. [R1-C3]

AI speeds up extraction — and coupling

Agents can compare repositories, identify repetition, propose templates and write migrations. The same speed may generalize too soon.

Before promoting a pattern, ask for:

• concrete examples in at least two contexts;
• differences that should not be erased;
• adoption and removal testing;
• ownership and versioning;
• impact on security and data;
• evidence that the pattern resolves repeated pain.

The agent finds similarities. The organization decides which similarities deserve to become dependencies.

What this article proves — and what it doesn't prove

Software development research argues that platform and organizational system influence AI adoption outcomes. Architectural sources support durable decisions and explicit roles. This doesn't prove that every company should build an in-house platform or that reuse always reduces cost.

This article proposes to treat the first product as a source of candidate assets. Promotion depends on observed repetition, ownership, testing and actual savings.

Conclusion

The first product is worth the results it delivers and the capacity it leaves behind. The factory of the second is not an abstract layer built before the market; it is operational knowledge extracted from actual work.

Product learns from customer. Platform learns through repetition. Method learns from decisions. When the three connect, each release can reduce the cost of learning the next.

Previous reading: Solo founder + AI squad. Next suggested reading: Context engineering.