What a production product costs beyond the prototype

Prototypes have become dramatically easier to produce. A capable person can now turn a specification into a convincing interface, working demonstration, or narrow application faster than the planning cycle that used to precede it.

That progress is real. It does not remove the work required to make software dependable under customer, commercial, and operating conditions.

The useful cost question is no longer simply “How many screens does the MVP need?” It is “What must this product be responsible for when real people and money depend on it?”

A prototype proves possibility

A prototype can show that an interaction makes sense, that a workflow is technically possible, or that users respond to a product concept.

It may be entirely appropriate for:

• testing language and positioning;
• demonstrating a workflow;
• learning from a small group of users;
• exploring an interaction model;
• proving that an integration can work;
• creating evidence before a production investment.

Its value comes from learning quickly. That does not require every production obligation to be present.

A production product accepts responsibility

A production product must behave safely when the easy assumptions stop holding.

The scope often expands around six obligations.

Identity and access

The product needs to know who can enter, which organization or account they belong to, what they may see, and what happens when that access changes.

Data lifecycle

Records need ownership, validation, history, retention, deletion, synchronization, and recovery behavior. Duplicate and interrupted requests need defined outcomes.

External effects

Payments, messages, integrations, and generated work can succeed outside the application while the local request appears to fail. Production code has to reconcile those states without charging, sending, or creating twice.

Administration

Someone needs a safe way to inspect and correct routine conditions without editing production data directly.

Delivery and recovery

Environments, configuration, migrations, releases, health checks, logs, backups, and recovery paths make the product operable after the first deployment.

Continued ownership

A person must remain responsible for failures, product decisions, support context, and the next improvement.

These obligations—not visual polish alone—create much of the difference between a generated application and an operating product.

Cost follows consequential complexity

Two products with the same number of screens can require very different production scopes.

A read-only reference tool may tolerate delayed updates and simple access. A product handling money, private records, offline work, approvals, or regulated workflows cannot.

The most consequential cost drivers are usually:

• the number and responsibility of user roles;
• the sensitivity and history of the data;
• the consequence of a failed or duplicated action;
• the reliability of external systems;
• the number of operating surfaces;
• offline or background behavior;
• launch and distribution constraints;
• the amount of existing code and data that must be preserved;
• the level of support and operation required after launch.

This is why a fixed feature menu produces weak estimates. It counts visible outputs while ignoring the conditions under which those outputs must keep working.

Existing code changes the estimate

An AI-built prototype or inherited codebase may reduce implementation work when its structure matches the intended product and its behavior can be verified.

It may also increase the initial work when:

• access rules are distributed across the interface;
• data assumptions are not written down;
• generated dependencies create conflicting patterns;
• tests exercise components but not critical outcomes;
• deployment state exists only in one person’s environment;
• the fastest repair is replacing a boundary rather than extending it.

The code should be treated as evidence, not automatically as an asset or a liability. The estimate should follow inspection.

Price the first complete operating loop

The first engagement should be large enough to produce a meaningful production outcome, but narrow enough that decisions remain reversible.

A strong first scope typically connects:

1. one commercially meaningful user outcome;
2. the data and permissions required for it;
3. the external services on its critical path;
4. the minimum administration needed to operate it;
5. deployment and observability;
6. verification under expected failure conditions.

Capabilities outside that loop can be deferred explicitly.

Prodmake focused first stages start at $10,000, while production builds commonly begin at $25,000. Every first stage must produce a useful, inspectable outcome; it is not a paid estimate or generic discovery phase.

Larger systems proceed through additional written stages as operating evidence and product decisions become clearer.

A useful estimate states its assumptions

A responsible estimate should make these elements inspectable:

• the intended operating outcome;
• included product surfaces;
• important constraints;
• existing assets being relied on;
• explicit exclusions;
• acceptance evidence;
• responsibilities during launch;
• conditions that would require a scope change.

The estimate is useful because it explains the shape of the work, not because it presents an exact number before the product has been understood.

Spend against uncertainty deliberately

The goal is not to make every possible production decision before implementation. It is to remove the uncertainties most likely to create expensive reversal or unsafe behavior.

A prototype can answer whether an idea is coherent. A production engagement answers whether the complete system can launch, operate, and continue improving under one accountable owner.