Treat the prototype as evidence, not as production source code.

A finished-looking AI-generated product compressed the design conversation. The production work was deciding what it had resolved, what still needed proof, and what required a maintainable system.

A valuable prototype with a different production job.

A stakeholder arrived with an interactive product prototype generated with AI. It already expressed navigation, interface states, visual direction, and product intent clearly enough to reduce design ambiguity.

  1. Context: a clickable product argument

    The prototype made the intended experience concrete before production engineering began.

  2. Role: audit and implementation

    Marga’s contribution covered source assessment, engineering decisions, and the WordPress/React rebuild.

  3. Constraint: confident output needed evidence

    Derived health states, content relationships, and data presentation could look plausible while still needing review.

  4. Direction: preserve intent, replace fragility

    Useful product decisions became a specification; production behavior moved into systems that could be tested and maintained.

Separate product decisions from assertions.

Generated code presents layout choices, calculations, labels, and health statements with the same confidence. The audit used a more useful split: preserve decisions that expressed stakeholder intent, then verify every assertion about data, behavior, or the body before carrying it forward.

  1. Decisions to preserve

    Information architecture, interaction intent, visual hierarchy, and useful interface states formed a strong implementation brief.

  2. Assertions to verify

    Calculated states, content relationships, accessibility, safety language, and persistence behavior required direct inspection and testing.

Look for failures a click-through cannot reveal.

The strongest findings were not visibly broken screens. They were gaps between individually plausible parts of the prototype. Three questions kept the review focused without turning the case study into a feature inventory.

  1. Can the state model represent the exception?

    Derived-state logic was reviewed beyond the happy path so the interface would not turn an unsupported condition into a confident answer.

  2. Do related surfaces share one source?

    Content shown in one surface and selected in another needed a single structured model rather than separate plausible literals.

  3. Is the data understandable without color alone?

    Data colors, contrast, labels, focus states, and accessible names were treated as product behavior rather than visual polish.

Translate intent instead of porting implementation.

The prototype stayed useful as an interactive reference. The production architecture changed around it so maintainable content, data, and application behavior no longer depended on one generated artifact.

  1. Keep: product intent

    Retain the useful flow, hierarchy, interaction direction, and interface decisions that the stakeholder could already inspect.

  2. Rebuild: production systems

    Move editable content into WordPress, application UI into a typed React build, and user data into a deliberate production persistence model.

  3. Omit: unsupported certainty

    Do not inherit unreviewed health language, misleading AI labels, sensitive implementation detail, or claims the available evidence cannot support.

Hand back a product the stakeholder can operate.

The practical outcome was a clearer operating model: WordPress managed structured content, the application used maintainable data systems, and product assertions had an explicit review boundary. The stakeholder could update supported content without regenerating the application source.

This public account intentionally stops there. It does not use delivery counts as outcome metrics, imply medical validation, or claim performance and business effects that were not approved for publication.

Turning a prototype into a maintainable product?

Share the prototype, product decisions, content workflow, data needs, and known review constraints. The Custom WordPress Development service explains the implementation path, or start with a practical conversation.