From prototype to operation: what to clarify before real use

The first user changes the task

A prototype asks whether an idea is technically possible, understandable or interesting. Once an organisation uses it regularly, other expectations arise: data must survive, failures need a contact, and changes must not unexpectedly interrupt important work.

This is not an argument for burdening every prototype with a large operations organisation. Preparation should match actual use. A public information site, internal note tool and school meal application need different standards. But those standards must be explicit.

These questions are my proposal for a discussion before real use. They do not replace evaluation of the specific application.

1. Which workflow must work?

“The application is reachable” is a weak goal if its essential function cannot be used. For ordering, can an authorised person complete an order within the allowed time? For information, can people find and understand the right details?

Expectations follow from the workflow: how current must the data be, what interruption can be managed, and what counts as a noticeable failure? Google’s SRE Workbook uses an example service-level objective documentto show explicit goals and measurements. Small applications can use the principle too; target values must fit the task.

2. Who takes which responsibility?

Technical support is only part of it. Someone must also answer domain questions, grant access and decide on changes. In small projects one person may hold several roles, but they should still be named.

A brief operational contact note is often more useful than extensive documentation with no owner: who is reachable, where are problems reported, what information helps diagnose them and who covers absences?

3. How is a failure noticed?

A server can run while a business process fails. Monitoring should therefore match the important workflow. Technical errors, user feedback and checks of key functions complement each other.

The goal is not to maximise notifications. An alert should enable a concrete response. If nobody knows what to do after a message, the operational design is incomplete.

4. What happens to the data?

A backup is initially a stored copy. Its usefulness in an emergency is established through restoration: what data does it contain, what changes could be lost between backups, and what access and tools are needed to restore it?

These questions belong in the design, as do secure handover or deletion at the end of a collaboration. A readable export may matter more to an organisation than another convenience feature.

5. How are changes deployed?

A new release changes a running system. Keep track of the deployed version and its checks. Data changes need particular care: reinstalling an old program version does not automatically undo a data migration.

A simple documented process may suffice for a small service. What matters is not thinking through a failed change for the first time under pressure. Google’s account of Production Readiness Reviews places these questions within a broader assumption of operational responsibility.

6. What is explicitly not covered yet?

A limited launch can make sense. State its limits: intended users, functions and support. An explicit limitation can be handled together. Unspoken expectations often become visible only when something goes wrong.

Schulmittag is an example in my project directory of connecting product and ongoing operations. Schulnavi shows another side: responsibility for data origin and clarity. The common question remains what people may actually expect from a system.