All guides

Product delivery

The demo works. What gets it ready for real users?

An open blue box containing a compact device, illustrating product release and handover
Illustrative image, generated with AI.

A promising demo is a great start. Real use adds permissions, unusual inputs, unreliable connections and people who need help when something fails. The next step is to turn that promise into a product your team can operate.

Test with intended users

The selected example worked. Now try the missing document, the unclear request and the person who uses a different device. Build the review set around real work rather than the path everyone already knows.

Look at the consequences of mistakes. A poor suggestion, an exposed record and a duplicate update need different responses. Agree when the system should continue, ask a question or hand the task to a person.

Define permissions and approval requirements

An application may read external documents and tool responses that contain untrusted instructions. It must still enforce which records and actions the user is allowed to access. OWASP’s excessive-agency guidance recommends limiting capabilities and requiring human approval for high-impact actions.

Keep credentials in the appropriate server environment and record consequential operations. Hiding a button does not enforce a permission. Test the whole path from user action to connected system.

Implement monitoring and recovery

Plan what happens when a service is slow or unavailable. Use controlled retries where appropriate, useful error messages and enough monitoring to tell a bad answer from a broken connector.

Agree which user journeys matter most and what level of service they need. Google’s SRE framework can help structure that discussion. Avoid recording more sensitive content than necessary just because it makes troubleshooting convenient.

Plan rollout and operational support

Start with a manageable group, review what happens and expand when the evidence supports it. Keep a known-good version and a recovery plan. Name who can approve a release and who responds to a problem.

A release should arrive with operating guidance and a handover, not only a URL. Once those foundations are in place, the team has more freedom to improve the product and explore the next useful feature.

Before you start

  • Test real inputs, invalid requests and dependency failures.
  • Verify access controls and approval gates.
  • Agree monitoring, escalation and rollback.
  • Complete a deployment and handover walkthrough.

Related engineering work

MaidInHK’s delivered recruitment journey combines multiple product functions. The case illustrates a complete platform scope; these production checks are recommended practice, not a disclosure of its internal infrastructure.

View the project case

Sources and further reading

Delivery and production handover