AI product finishing Anonymous case study

Anonymous case / rebuilt visuals

From an AI-built shell
to a usable first release

This was not a surface-level redesign. The real gap was that pages, interactions, maintenance, and verification had not yet become one deliverable product path.

Starting point
AI-built front-end shell
Scope
One critical workflow
Evidence
Rebuilt visuals + verification

02 / The problem

Common gaps in AI-built prototypes

Pages existed.
A stable product did not.

These are common market patterns, not a claim that every issue existed in the original project. Together, they describe the gap between a visual demo and a product that can be handed to real users.

P-01

Looks finished, hard to maintain

Several public pages exist, but updates still require code changes or fail to appear consistently on the live site.

P-02

Each page speaks a different language

Fields, labels, actions, and feedback vary across pages created at different stages, so users cannot build a stable expectation.

P-03

Only the happy path exists

Empty, failed, and recovery states are missing. The experience breaks as soon as real use moves away from the demo path.

P-04

Easy to generate, hard to change safely

Without clear boundaries and acceptance rules, later AI edits overwrite one another and maintenance cost rises with every page.

03 / The decision

Scope control

Do not rebuild everything. Close one vertical workflow first.

The question changed from “How many pages exist?” to “Can one real user complete the path?” Each step needed a clear input, result, and next action.

  1. 01
    Maintain content in the admin Fields and status share one source
  2. 02
    Show the same data publicly Catalog and detail use one language
  3. 03
    Let people review records Available and requestable material is clear
  4. 04
    Continue to human enquiry The next step has clear boundaries
Completion rule

The admin can update it, the public page matches it, users can understand it, exceptions can recover, and the real version can be verified.

04 / Before and after

Anonymously rebuilt from real project problems

Not simply prettier.
Clearer about what happens next.

Both views are fictional interfaces rebuilt for this case. They preserve the problem structure and product decisions, but they are not original client screenshots.

View
Before / visual shell

Generic item detail

Rebuilt example
COLLECTION Home　About　Contact
Collection item

Archive Study A-17

Price on request

A selected work in good condition. Contact us to learn more.

Date: —Provenance: —Files: —
  • The enquiry is generic, so people do not know what they can ask for.
  • Key records are missing, with no explanation of what can be requested.
  • The catalog, detail page, and admin have no visible shared structure.
After / finished workflow

Verifiable, requestable, maintainable

Rebuilt example
ARCHIVE / CATALOG Catalog　Records　Private enquiry
Catalog ref A—17 · Available to view

Untitled Composition Study

Works on paper / mid-20th century / dimensions recorded

Provenance summaryAvailable
Condition reportOn request
or continue to private enquiry
01 Provenance02 File status03 Viewing
  • Catalog and detail pages use the same reference and record language.
  • Available records, requestable records, and human confirmation are separated.
  • Public fields map back to maintainable admin fields instead of temporary copy.
01From generic enquiry to record review

Original issueThe only action was “Contact us,” with no clue about what could be reviewed first.

DecisionA high-consideration decision should reduce uncertainty before asking for contact.

OutcomeShow record status first, then offer a condition report and human enquiry.

02From scattered fields to one content model

Original issueThe catalog, detail page, and maintenance side described the same information differently.

DecisionConsistency reduces both user confusion and maintenance cost.

OutcomeReferences, status, and record fields now use one shared structure.

03From happy path to recoverable states

Original issueMissing records or failed loading left blank space or inactive actions.

DecisionA real product must explain what happened and what a user can still do.

OutcomeEmpty, failed, and human-confirmation paths keep the workflow from ending silently.

05 / What changed

Organized by product layer, not code files

Four layers, serving one path

Each layer explains why it changed and what became possible. The goal is to show product value, not a long list of technical activity.

01

Information structure

Aligned page hierarchy, record fields, references, and business language across the catalog, detail view, and admin.

Less ambiguity
02

Key interactions

Separated record review, report requests, and human enquiry into three understandable actions.

A predictable next step
03

Maintenance path

Made admin changes appear consistently on public pages and limited further copy and field drift.

Lower change cost
04

Quality pass

Handled mobile layout, empty states, failure feedback, visible bugs, and the actual live entry version.

From demo to use

06 / Completion evidence

Not “I changed it,” but something that can be checked

Completion lives in the real version and its states

Only verification types that were actually used are listed here. No automated coverage, test counts, or business outcomes are invented.

  1. 01
    Desktop and mobile review

    Core information, actions, and reading order remained usable across key widths.

    Reviewed
  2. 02
    Admin-to-frontend consistency check

    Maintained content and status appeared consistently on the public pages.

    Reviewed
  3. 03
    Success, failure, and empty-state check

    The workflow still explained what happened and offered a recovery action.

    Reviewed
  4. 04
    Build and deployment check

    The build output entered the deployment path instead of remaining only in local source files.

    Completed
  5. 05
    Live entry version check

    The user-facing entry pointed to the expected version and was confirmed with reviewable evidence.

    Confirmed

07 / Scope

A small first engagement

Start with the workflow that blocks real use

This work is not a promise to take over everything. Scope, completion rules, and responsibility need to be clear first.

A good fit

An existing shell that needs one complete path

  • An existing AI prototype, template, or unfinished product.
  • One critical workflow, 1–3 pages, or a minimal admin path to finish.
  • Existing code, a real goal, and the necessary business context are available.
  • The result can be checked through clear pages, states, and the real environment.
Not included

Unbounded rebuilds and high-risk systems

  • Full-site rebuilds without a boundary or ongoing unlimited maintenance.
  • Complete transaction, payment, fulfilment, logistics, or complex permission systems.
  • Security audits, legal compliance, or guaranteed business outcomes.
  • Vague requests with no clear completion rule.