THE SHORT ANSWER

Before launch, confirm the production domain, hosting, configuration, data handling, monitoring, support ownership and rollback approach. Release in a controlled way, watch critical journeys and operational signals, and reconcile external services. After launch, combine user feedback, behavior, reliability and business outcomes to prioritize improvements.

Prepare the service around the code

  1. Production domain, hosting and deployment route
  2. Protected production configuration and credentials
  3. Data migration, backup and recovery
  4. Monitoring for availability and critical operations
  5. Analytics tied to defined questions
  6. Support contact, ownership and escalation
  7. Release and rollback steps
  8. Known limitations and launch decision

A passing build is evidence about the software artifact. It does not confirm that production configuration, third-party services or operational ownership are ready.

Evidence & context: MDN Web Docs · NIST

Control the release and observe real journeys

Use the established deployment path, record the released version and verify production rather than assuming a successful upload equals a working service. Exercise representative journeys and confirm their downstream records, messages or provider events.

Where risk is high, limit exposure or phase access so the team can learn before expanding.

Evidence & context: GOV.UK Service Manual

Measure outcomes and product health

Four evidence streams
EvidenceQuestion
User research and supportWhere are people confused, blocked or underserved?
BehaviorWhere do journeys begin, progress and stop?
ReliabilityWhich operations fail, slow down or require manual recovery?
OutcomeIs the product creating the intended user and organizational result?

Analytics needs interpretation and data-quality checks. It should not replace direct research or operational evidence.

Evidence & context: Google Analytics Help

Run an evidence-led improvement loop

Collect evidence → frame the problem → estimate value and risk → choose a small change → test it → release it → observe the result. Keep a decision log so the team understands why priorities changed.

Use the Startup go-to-market guide for market execution and the measurement framework for deeper analytics design.

Sources & further reading

  1. How the web works

    MDN Web Docs. Standards-oriented learning material on clients, servers, DNS, HTTP and browser rendering. It is a simplified conceptual introduction rather than a complete architecture guide.

  2. Quality assurance: testing your service regularly

    GOV.UK Service Manual. Government guidance on usability, functional, performance, security, accessibility and continuous testing. It does not prescribe one universal test suite.

  3. Understand user metrics

    Google Analytics Help. Official definitions for total, active, new and returning users. Identity limits and configuration can affect interpretation.

  4. Secure Software Development Framework

    NIST. Outcome-based secure-development guidance covering preparation, protection, secure production and vulnerability response. It is a framework, not a product-specific checklist.

Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.

A correction, a counterexample or an experience worth sharing?

Join the conversation ↗