When each visitor needs different private information
Customer portals, order histories and account dashboards need controlled access to individual data. Publishing that information into public pages is not an acceptable shortcut. The project needs authentication, authorisation and an operational data model appropriate to its purpose. A separate public marketing site may still be useful, but it does not replace the private application.
When availability changes during the decision
Stock reservation, seat allocation and appointment confirmation involve state that can change between visitors. A catalogue can describe an item without promising that a unit is available. If the visitor needs a binding transaction, use a system designed to handle it and define how errors, cancellations and payments will be managed.
When the editorial workflow is the main product
A large publishing team may need scheduled releases, detailed permissions and rapid revisions throughout the day. These are real operating requirements, not inconveniences to dismiss. Assess the tools and training needed before recommending a simpler site. Reducing one technical dependency is not worthwhile if it makes the business unable to publish reliably.
A practical next step
What to prepare.
- Critical workflows
List anything that would stop operations if it became a manual enquiry.
- Data boundaries
Identify information that must never become a public page asset.
- Publishing demand
Describe team size, approval roles and expected turnaround for edits.
Questions worth asking.
Should we abandon a public-site rebuild?
Not necessarily. Public information can be improved separately while operational functions remain in appropriate systems.
Can a button replace checkout?
A quotation request can support a different sales process, but it is not equivalent to a completed online purchase.
What should we ask in discovery?
Ask how every essential workflow will operate after launch, including exceptions and responsibility for failures.